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This is one of two books that describe, at the implementation level, the Systems Network Archi- 
tecture (SNA) logical unit (LU) type 6.2 protocols. This book concerns the SSCP-independent LU 
6.2 protocols (or peer protocols, not requiring mediation by a system services control point 
during LU-LU session initiation); the second book, SNA Format and Protocol Reference Manual: 


Architecture Logic for LU Type 6.2, SC30-3269, concerns the SSCP-dependent LU 6.2 protocols 


initiation). LU-LU protocols not related to session-initiation and -termination are common to 
both SSCP-dependent and -independent LU 6.2 protocols; these common protocols will be updated in 
the future only in this book, which therefore has precedence over the other book for information 
on these protocols. 


This book does not describe any specific machines or programs that may implement SNA», nor does 
it describe any implementation-specific subsets or deviations from the architectural description 
that may appear within any IBM SNA product. These matters, as well as information on SNA prod- 
uct installation and system definition, are described in the appropriate publications for the 
particular IBM SNA machines or programs to be used. 


The following books should be read in conjunction with this one. 


_ COREQUISITE PUBLICATIONS 


‘ 
CC 


e SNA Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2; 


SC30-3269—reference information on SSCP-dependent protocols for LU 6.2. 


e SNA Transaction Programmer's Reference Manual for LU Type 6.2, GC30-3084—reference informa- 


e SNA Formats, GA27-3136—information on LU 6.2 and other SNA formats. 


PREREQUISITE PUBLICATIONS 


@ SNA Concepts and Products, GC30-3072—basic information on SNA for those readers wanting 
either an overview or a foundation for further study. 


e =6©6SNA Technical Overview, GC30-3073—additional details on SNA, especially on functions and 
control sequences; bridges the gap between the most elementary overview of SNA and the 
detailed descriptions of the formats and protocols. 


RELATED PUBLICATIONS 


* 


e SAA Common Programming Interface: Communications Reference, SC26-4399—description of Sys- 
tems Application Architecture's!? Communications Interface, which provides a high-level pro- 
gramming interface to LU 6.2. 


e SNA Format and Protocol Reference Manual: Architectural Logic, SC30-3112—comprehensive 


e SNA—Sessions Between Logical Units, GC20-1868—reference information on SNA formats and 


protocols for LU types other than type 6.2. 


1 Systems Application Architecture is a trademark of International Business Machines Corpo- 


ration. 
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e SNA Type 2.1 Node Reference (abbreviated T2.1 Node Reference), SC30-3422—reference informa- 
tion on type 2.1 node protocols. ( 


e SNA Format and Protocol Reference Manual: Distribution Services, SC30-3098--reference ~~~ 


information on formats and protocols for SNA Distri 1on Services. 


e Document Intercha Architecture--Concepts and Structures, SC23-0759--reference information 
on Document interchace Architecture. | 
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CHAPTER 1. 


INTRODUCTION | 


USE AND ORGANIZATION OF THIS BOOK 


This book, in conjunction with the companion 
books listed in the Preface, provides a 
formal definition of Systems Network Archi- 
tecture (SNA). It is intended to complement 
individual SNA product publications, but not 
to describe individual product implementa- 
tions of the architecture. 


SNA logical unit type 6.2 (hereafter general- 
ly referred to as LU 6.2, or simply LU) is 
defined here in the form of a functionally 
layered system, represented by a= formal 
description, that is decomposable into compo- 
nents called protocol machines. Protocol 
machines generate output sequences in 
response to input sequences, in accordance 
with fixed rules, or protocols, governing 
distinct information transfers into, out of; 
and within the system. 


The protocol machine definition of SNA uses 
the following basic notions: 


e Finite-state machines: A_ finite-state 
machine (FSM) is an abstract device hav- 
ing a finite number of states (memory) 
and a set of rules whereby the machine's 
responses (state transitions and output 
sequences) to all input sequences are 
well defined. 


e Routing and checking logic: Routing and 
checking logic performs a mapping of 
inputs (message units and FSM states) 
into outputs. It is used to verify 
validity of message units and to route 
them to FSMs. 


e Block diagrams: A block diagram repres- 
ents the decomposition of a protocol 
machine into its component submachines 
(which themselves are protocol machines ) 
and the signaling paths between them. 
Each block in the diagram can be further 
decomposed into its constituent subma- 
chines. 


¢ Protocol boundaries: A protocol boundary 
1s a specification of the format and con- 


tent requirements imposed on the signals 
exchanged between protocol machines with- 
in the same node. 


The remainder of the book presents details of 
the SNA formats and protocols for LU 6.2; 
arranged as follows: 


e Chapter 2 provides an overview of the 
functions and structure of the LU, as 
well as the sequences and message units 
exchanged between two communicating LUs. 


e Chapters 3 and 4@ describe LU services 
manager components; these components 
attach transaction programs as requested, 
allocate sessions to transaction pro- 
grams, and coordinate the activation and 
deactivation of sessions involving LUs. 


e Chapters 5.0 through 5.4¢ describe the 
general structure and detailed functions 
of presentation services—in particular 
the execution logic for LU 6.2 verbs. 


e Chapter 6.0 provides an overview of the 
half-session, while Chapters 6.1 and 6.2 
describe the data flow control and trans- 
mission control protocols, respectively, 
within half-sessions. 


e Appendix A describes the data structures 
used in the formal description and the 
relationships among the control blocks. 


e Appendix B describes the basic functions 
of the buffer manager and its protocol 
boundary with the LU. 


e Appendix N describes the basic concept 
of,» and notation for, finite-state 
machines. 


e¢ Appendix T provides a comprehensive list 
of abbreviations and acronyms used in the 


book. 
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GENERAL CONCEPTS 


DEFINITION OF AN SNA NETWORK 


An SNA network: 


¢ Enables the reliable transfer of data 
between end users (typically, terminal 
operators and application programs). 


® Provides protocols for controlling the 
resources of any specific network config- 
uration. | 


An SNA network consists logically of a set of 
network addressable units (NAUs) intercon- 
nected by an inner path control network con- 
sisting of the path control, data _ link 
control, and physical layers; Figure 1-1 on 
page 1-2 shows’ the general relationships. 
SNA networks functionally have a layered 
organization, the outermost layers of which 
form the NAUs, A NAU consists of the upper 
layers, transaction services (TS) and presen-_ 
tation services (PS), and one or _ more 
half-session protocol machines (consisting of 
the data flow control and transmission con- 
trol layers), depending on the number of oth- 
er NAUs with which it can be paired to form 
sessions. 


Those NAUs serving end users are called log- 
ical units (LUs). An LU allows an end user 
to gain access to network resources (such as 
links, programs, and directories) and to com- 
municate with other end users. An LU may 
also provide a service (such as for a control 
operator) wholly contained within the LU that 
1s accessed from another LU via a session. 
Thus» in some cases, an LU-LU session has an 
end user only at one end. The presence of 
various services within an LU is a _ function 
of LU type, product design, and installation 
options. 


In general, there need not be a one-to-one 
relationship between end users and LUs. The 
association between end users and the set of 
LUs is an implementation design option. 


The LUs provide protocols allowing end users 
to communicate with each other and with other 
NAUs in the network. An LU can be associated 
with more than one network address (or with 
multiple, distinct local-form session identi- 
fiers); this allows two LUs (and therefore 
their end users) to form multiple, concur- 
rently active sessions with each other. 


Besides LUs, two other network addressable 
units are defined: physical units (PUs) and 
system services control points (SSCPs). 
These NAUs,s in conjunction with one another, 
with control points (CPs) in T2.1 nodes, and 
with LUs, provide a variety of session, con- 
figuration, management, and network-operator 
services. 


Message units are transported between NAUs by 
the path control network. These message 
units are of the general form: 


MSG = (session routing information ,other 
parameters, and data) The path control net- 
work routes and delivers message units to naj 
in the same order as sent from nai. 


The message units transferred within an SNA 
network generally have two components: 
end-user information and control information. 
The end-user information is passed by the SNA 
network and does not affect its state. Con- 
trol information may sometimes be passed to 
the end users (as in the case of the Change 
Direction indication, which allows one end 
user to transfer the right to transmit data 
to the other); however, its main purpose is 
to change the state of the SNA network, thus 
effecting a normal control change (such as a 
change to a path control routing table) or a 
recovery from an exception condition. 


NODES 


The SNA network physically consists of nodes 
interconnected via links. An SNA node is a 
grouping of SNA-defined protocol machines. 
An SNA product node may consist of addi- 
tional, product-specific protocol machines 


that use one or =more SNA _ nodes. A 
user-application node may consist of addi- 
tional, ins tallation-def ined protocol 


machines that use one or more SNA product 
nodes. These relationships are shown in Fig- 
ure 1-2 on page 1-4. The abstraction of 
nested nodes is a useful reminder that each 
product exists in an environment that con- 
tains many design features that are not 
defined by SNA. 


For specific details of nesting of SNA nodes 
and SNA product nodes within user-application 
nodes, see SNA Concepts and Products and SNA 
Technical Overview. — —— 


In this book, "node" is synonymous with "SNA 
node," and the qualifier will generally be 
omitted. Thus, end users’ and protocol 
machines not defined in SNA are external to 
the node, as that term is used hereafter. 


Various node types are defined in SNA: types 
1, 2.0, 2.1, 4, and 5. They are distin- 
guished by varying capabilities, such as for 
interconnection, and by the presence or 
absence of different NAU types. 


For example, type 2.1 nodes can connect to 
the general subarea routing network or to 
other type 2.1 nodes directly. In the former 
case, subarea nodes (discussed below) provide 
general intermediate routing within the path 
control layer, allowing complex network con- 
figurations to be fashioned; in the latter 
case, two type 2.1 nodes can interconnect 
independently of other nodes >» ina 
peer-to-peer relationship. 


Type 1 and type 2 (1.e., 2.0 or 2.1) nodes 
are also referred to as peripheral nodes; 


Chapter 1. Introduction 1-3 


User-Application Node 


(a) Typical Case 


User-Application Node 


(b)} Two SNA Nodes within an SNA Product Node 
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User-Application Node 


(c) Two SNA Product Nodes within a User-Application Node ae, 


Figure 1-2. Examples of Nested Nodes 


because they have limited addressing and 
path-control routing capabilities. They do 


al nodes attached to the subarea node.) Sub- 
area nodes, besides also being sources and 
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not participate in the general network rout- 
ing based on a global network address space. 
Instead, they depend on “boundary function" 
support in types 4 or 5 nodes to transform 
between the address forms, local to the 
peripheral nodes, and the network addresses 
used in the general routing portion of the 
path control network. Peripheral nodes are 
thereby insulated from changes in the global 
network address space resulting from reconf- 
igurations. 


Types 4 and 5 nodes are referred to as sub- 
area nodes. (A subarea represents a parti- 
tioning of the network address space. It 
contains a subarea node and all the peripher- 
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sinks of data, have more general path control 
capabilities. They can perform intermediate 
routing—passing message units received from 
one node on to another—and provide adaptive 
control of traffic flow within the subarea 
routing portion of the network. 


NAUS AND NODE TYPES 


Except for a T2.1 node, a node always 
includes a physical unit (PU), which controls 
the attached links and various’ other 
resources of the node. A PU has a type des- 
ignation corresponding to the type (1, 2.0, 


4, or 5) of node in which it resides. A T2.1 
node includes the PU functions within its 
local control point (CP), described further 
below. 


A node typically also includes logical units 
(LUs), through which end users attach to the 
node, and thus to the SNA network. From the 
vantage of this and the companion LU 6.2 
book, node types 2.1 and 5 are of primary 
interest, as these are the only nodes that 
include LU 6.2 implementations. This book 
focuses on the SSCP-independent LU 6.2 proto- 
cols, and emphasizes interactions within the 
T2.1 node to support these peer protocols. 


A subarea PU or subarea LU resides in a sub- 
area node. A peripheral PU or peripheral LU 
resides in a peripheral node. 


Type 5 nodes each contain a system services 
control point (SSCP). (Type 4 nodes do 
not—the primary architectural distinction 
between subarea node types.) An SSCP sup- 
ports protocols for management and control of 
a domain. A domain consists of one SSCP and 
the PUs, LUs, links, and link stations that 
the SSCP can activate. Each PU, LU, link; 
and link station in a network belongs to one 
of the domains comprising the network, and 
some can belong to more than one domain—a 
feature referred to as "shared _ control." 
Each SSCP provides network services within 
its domain (basically for converting local 
names to global addresses) through protocols 
supported in conjunction with the PUs or LUs 
in the domain. The multiple SSCPs ina net- 
work jointly support network services across 
domains. 


Type 2.1 (T2.1) nodes each contain a control 
point (CP), which provides services on a more 
local scale than an SSCP provides. In par- 
ticular, a T2.1 CP can mediate LU-LU 
session-initiation requests (by doing 


This section describes some notational con- 
ventions widely used in both the figures and 
the text. (Additional conventions ' are 
defined within figure legends throughout the 
book. ) 


A naming convention, using qualifiers sepa- 
rated by periods to denote more specific com- 
ponents of a composite protocol machine, is 
used throughout the book. Component subma- 
chines are shown as blocks within a larger 
block that represents the composite machine. 


In many cases, it is desirable to identify a 
qualifier by a phrase of multiple terms, in 
order to better convey the meaning of the 
qualifier. The multiple terms in the phrase 
are connected by underscores to indicate that 
they are part of a phrase rather than sepa- 
rate qualifiers representing further decom- 
positions. The underscore convention is also 
used in names of states and data structures. 


partner-LU address look-up in its local data 
base) in the SSCP- ~ independent LU 6.2 context 
just as an SSCP does in the SSCP- PEP enaemt Lu 
6.2 context. 


THE PATH CONTROL NETWORK 


The system consisting of all interconnected 
path control (PC) and data link control (DLC) 
components forms the path control network. 
The input/output streams of the path control 
network consist of streams of control infor- 
mation, such as addresses, and associated 
user data. 


Each node has a PC element and NAUs. The 
node and link connections of the network, and 
the PC routing algorithms, combine to provide 
the following behavior for the path control 
network: 


e An input to a PC element in node-i from a 
NAU is transmitted and routed by the path 
control network and emitted as output by 
the PC element in node-j to the destina-~ 
tion NAU. (Since node-1 and node-j can 
be the same node (1=3), NAUs within the 
Same node can be connected by a session. ) 


e Message units with the same session iden- 
tifiers are emitted by the path control 
network in the order submitted by the 
origin NAU. 


Just as primary-secondary DLC asymmetries and 
other DLC details are hidden from PC, so the 
routing and other concerns of the path con- 
trol network are not visible at the protocol 
boundary with the NAUss; in particular, the 
path control network conceals the node inter- 
connections and the NAUs need only consider 
their logical connections (1.e., sessions) 
with other NAUs. 


Each protocol machine in the book has a 
unique name consisting of a sequence of qual- 
ifiers. For example, (MACHINE.PRI.X_SEND, 
MACHINE.SEC.X_RCV) and (MACHINE.SEC.X_SEND, 
MACHINE.PRI.X_RCV) are examples of two basic 
protocol machine pairs. This naming conven- 
tion produces protocol machine names that 
carry precise information on the role of the 
protocol machine and its relative position in 
the network structure. 


Two other symbols, "|" and "&," are used in 
names and expressions. The "|" symbol indi- 
cates one of several (or “either...or"). For 
example, MACHINE.(PRIISEC) means “either 
MACHINE.PRI or MACHINE.SEC." The "&" symbol 
is used to indicate composition. For exam- 
ple, MACHINE.(RCV&SEND) is the composite pro- 
tocol machine consisting of MACHINE.RCV and 
MACHINE .SEND. 
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Some of the protocol machines defined in the 
book interact directly with undefined compo- 
nents. These undefined components, called 
undefined protocol machines (UPMs), represent 
implementation and/or installation options 
that are not architecturally prescribed (be- 
ing product or user oriented). 


Within block diagrams, the following con- 
ventions indicate the type of interaction 
between components: 


e Solid arrows indicate data flow; between 
processes, this implies  send/receive 
(asynchronous) logic. 


e Dotted arrows indicate calling relation- . 


ships. 


e Dotted lines indicate data structure 


access. 


Message units exchanged between SNA compo- 
nents are also denoted by special notation, 
particularly in sequence flow diagrams. A 
message unit is either a request or a 
response, depending on the RH coding (see SNA 


Formats); these are denoted respectively by a 


request-unit name (here designated gener- 
ically by the term "RQ") and by RSP. 


RQ( QUAL) denotes a request having the proper- 


ty described by QUAL; for example, RQ(Begin 
Chain), or simply RQ(BC), denotes a request 
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whose RH is coded "Begin Chain." A similar 
convention applies to responses. For exam- 
ple, RSP(BIND) denotes a response to the BIND 
request—a response that echoes the request 
code "BIND." | 


The asterisk (*) character is used _ in 
sequence flows, as well as elsewhere, to mean 
"any value" (or "don't care"). For example, 
"xBC" means "BC or -BC"—where "-" is the 
standard symbol for “NOT." 


"Chapter 2. Overview of the LU" describes 
additional conventions used in sequence flow 
diagrams. 


logic in the formal 
description uses simple English, some 
control-structure elements (e.g.> 
if/then/else) common to most high-level lan- 
guages, and a few straightforward conventions 
that are generally clear in context. For 
example, a call is frequently shown in the 
form: “Call PROCEDURE(X, /Y> Z)"3; this 
results in calling PROCEDURE and passing it 
the arguments X, Y>, and Z. Perhaps, the only 
control-structure needing additional explana- 
tion is the select/when group: at most, one 
when-clause is executed in a given pass. 


The procedural 


Abbreviations commonly used in the text are 
listed at the back of the book (Appendix T) 
for easy reference. 


a. 


CHAPTER 2. OVERVIEW OF THE LU 
INTRODUCTION 


CONCEPTS 


Ne 
\ 
: 
! 


This chapter is an overview of logical unit 
type 6.2 (hereafter referred to simply as 
LU). The LU provides application programs 


AND TERMS 


DISTRIBUTED TRANSACTION PROCESSING 


Distributed transaction processing involves 
two or more programs, usually at different 
systems, cooperating to carry out some proc- 


essing function. This involves program 
intercommunication to share each other's 
local resources such as processor cycles, 


data bases, work queues», or human interfaces 
such as keyboards and displays. 


The LU supports distributed transaction proc- 
essing by serving as the port between the 
programs and the path control network. It 
allows a transaction program (TP) to invoke 
remote programs and to exchange data with 
them. 


All communication provided by the LU is 
program-to-program. Any end user that is not 
a program is represented to the LU by a pro- 
gram. For example, fixed-function terminals 
and their devices (e.g., Keyboards and dis- 
plays) present themselves as fixed programs 
(e.g.» microcode) that use the same LU func- 
tions as user-written application programs. 
Human users at workstations do not interact 
directly with the LU but rather with local 
workstation programming support, which in 
turn interacts with the LU. 


This program-to-program communication accom- 
modates a variety of distributed processing 
connections, including peripheral node _ to 
subarea node, subarea node to subarea node, 
peripheral node to peripheral node through 
the subarea network, and direct T2.1 node to 
T2.1 node. For example, an application pro- 
gram at an outlying site (a terminal or a 
distributed processor) might communicate with 
a data-base management system at a central 
processor to maintain consistency between 
regional and central records. For another 
example, systems programs in workstations 
might exchange files and documents with each 
other. 


Figure 2-1 on page 2-2 illustrates the role 
of the LU in relation to an SNA network. The 


with support functions for distributed trans- 
action processing. 


LU connects transaction programs to the path 
control network. The LUs activate sessions 
between themselves. The component of a ses- 
sion in each LU is called a half-session. 
Two or more sessions between the same pair of 
LUs are called parallel sessions. Multiple 
sessions can concurrently use e same phys- 
ical resources connecting the LUs. 7 


The logical connection between a pair of 
transaction programs is called a 
conversation. A transaction program initi- 
ates a conversation with its partner with the 
assistance of the LUs. While a conversation 
is active, it has exclusive use of a session, 
but successive conversations may use the same 
session. 


An LU may run many transaction programs suc- 
cessively, concurrently, or _ both. Each 
transaction program may be connected to one 
or more other transaction programs by conver- 
sations. Multiple conversations between dif- 
ferent pairs of transaction programs can be 
active concurrently» with each conversation 
using a distinct session. 


Conversations connect TPs in pairs, but any 
TPs directly or indirectly connected to each 
other by conversations are participating in 
the same distributed transaction. For exam- 
ple, if TP A and TP B are connected by a con- 
versation, and, concurrently, TP B and TP C 
are connected by a conversation, then TPs A, 
B, and C all are participating in the same 
distributed transaction. 


TRANSACTION PROGRAMS 


The direct user of the LU is an application 
transaction program (application TP). Appli- 


cation TPs are provided by the end user to 
carry out functions of distributed applica- 
tions. 


A transaction program is distinguished from 
programs in general by two characteristics: 
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the way it is invoked, and the communication A transaction program is invoked by another 
functions it initiates. transaction program by a mechanism calle... 


Attach. The invoKing transaction program 
initiates a conversation with another named 
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program. The invoked program is started run- 
ning and is connected to the conversation 
with its invoker. (In the case of the ini- 
tial program of a distributed transaction, 
the LU receives a START_TP record sent by a 
process external to the LU, e.g., the node 
operator facility [NOF], which prompts the LU 
to invoke a transaction program. For more 
information about NOF, refer to "Functions of 
Components of the Node External to the LU" on 
page 2-35.) 


A transaction program uses the LU to communi- 
cate with other transaction programs by issu- 
ing transaction program verbs (which are 
described in SNA_ Transaction Programmer's 
Reference Manual for LU Type 6.2). (In some 
cases» internal LU components also issue 
transaction program verbs on behalf of trans- 


action programs. ) 


Besides application transaction programs, 
distributed transactions can include trans- 
action programs provided by the LU itself; 
called service transaction programs (service 
TPs). These are SNA-defined transaction pro- 
grams within the LU that provide utility 
services to application transaction programs 
or that manage the LUs. They are attached by 
other transaction programs and they issue 
transaction program verbs to communicate with 
other transaction programs. For example, the 
LU includes service transaction programs for 
distributed operator control of the LU, by 
which control operators can determine the 
number of parallel sessions they will share, 
and for sync point resynchronization, which 
assists distributed transaction recovery fol- 
lowing transaction failure in certain circum- 
stances. Other service TPs provide document 
interchange services (using Document Inter- 
change Architecture [DIA]), which allow 
processors and workstations to synchronously 
exchange files and documents. Furthermore, 
SNA Distribution Services (SNA/DS) service 
TPs provide asynchronous distribution of 
files and documents. 


Different execution instances of the same 
transaction program could perform parts of 
the same distributed transaction at different 
LUs or parts of several different trans- 
actions at the same LU. 


CONTROL OPERATOR 


The LU control operator describes and con- 
trols the availability of certain resources 
(see "Resources"); for example, it describes 
network resources accessed by the local LU 
and it controls the number of sessions 
between the LU and its partners. 


The LU control operator is represented to the 
LU by a control-operator transaction program 
that interacts with the LU on behalf of, or 
in lieu of, a human operator. The relation- 
ship between the control-operator transaction 
program and the LU control operator is 
implementation-def ined. 


The control-operator transaction program 
invokes operator functions by issuing 
control-operator verbs. These verbs are 
issued by the control-operator transaction 
program to convey operator requests to the 
internal components of the LU. 
Control-operator verbs are described in SNA 
Transaction Programmer's Reference Manual for 
LU Type 6.2. _ 


RESOURCES 


The LU provides several Kinds of resources to 
support distributed transactions. 


Conversations connect transaction programs 
and are used by the transaction programs to 
transfer messages. A conversation is acti- 
vated when one transaction program attaches 
another. 


Associated with each end of a conversation 
are protocol states that each LU maintains in 
order to coordinate interaction between the 
two TPs. These indicate (for example) which 
TP is sender and which is receiver at a given 
time. 


The LU provides two types of conversations. 
Mapped conversations allow the TPs_ to 
exchange arbitrary data records in any format 


set by the programmers. 


Basic conversations allow TPs to exchange 
records containing a two-byte Length prefix. 


Application transaction programs’ typically 
use mapped conversations, and service trans- 
action programs typically use only basic con- 
versations; however, either conversation type 
might be used by either program type. 


Sessions provide relatively long-lived con- 
nections between LUs; a session can be used 
by a succession of conversations. Sessions 
are activated by LU pairs as a result of 
operator commands and transaction-program 
requests for conversations. Session aware- 
ness by the transaction program is unneces- 
sary for successful communication. Most 
transaction programs need be concerned only 
with conversations, leaving the LU to manage 
sessions. 


A mode is a set of characteristics that may 
be associated with a session. These charac- 
teristics typically correspond to different 
requirements for cost, performance, and so 
forth. Modes are defined by the control 
operator as a selection of 
path-control-network facilities and LU 
session-processing parameters. 


One characteristic of mode is’ class of serv- 
ice. The path control network can offer dif- 


ferent classes of service that correspond to 


particular physical links and routes and par- 
ticular transport characteristics such as 
path security, transmission priority, and 


bandwidth 
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Other characteristics of mode include 
operator-selected processing parameters such 
as message-unit sizes and the number of mes- 
sage units sent between acknowledgments (pac- 
ing window sizes). 


Each mode. characterizes a group of sessions 
with a particular partner LU; multiple modes 
may exist for the same partner LU. Modes 
associated with different partner LUs are 
considered distinct, even if they represent 
similar sets of characteristic 

A combination of partner LU and mode is 
called an (LU,mode) pair. 


LU-accessed network resources constitute the 
relatively static environment that the LU or 
its containing node establishes as a result 
of installation definition. The principal 
components of this environment are the LU 
itself, the control point that serves the LU, 
the transaction programs that the LU can run, 
the potential partner LUs (remote LUs) with 
which the LU can communicate, and the modes 
of service available between the LUs. 


Local resources are resources whose principal 
functions and operations are not defined by 
SNA, but which LU components use or interact 
with for some functions. These include local 
files, data bases, recovery and accounting 
logs, queues, and terminal components. For 
example, LU components interact with local 
data-base managers to coordinate distributed 
error recovery of data-base updates. Also, 
SNA distribution services uses queues’ to 
exchange messages between application trans- 
action programs that provide document routing 
and distribution. 


Protected resources are local resources, such 
as data bases, whose state changes are logged 
so that all resources changed by a_ trans- 
action can be restored to a consistent state 
in the event of a transaction failure. The 
LU interacts with protected resources to pro- 
vide the sync point function (see "Sync Point 
Function" on page 2-37) for distributed error 
recovery. 


PROTOCOL BOUNDARIES 


In order to accommodate LU implementations on 
different processors and transaction programs 
written in different programming languages > 
SNA defines the LU's interface to application 
transaction programs in generic terms only. 
This specification is called the transaction 
rogram protocol boundary. It consists of 
the set of LU functions that a TP may 
request, and the possible parameter values 
that may be supplied or returned for these 
functions. 


SNA does not define a particular syntax or 
format for representing these functions and 
parameter values. Nevertheless, for purposes 
of discussion in SNA publications, the func- 
tions and parameters are represented gener- 
ically by transaction program verbs; these 
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are described in SNA Transaction Programmer's 


Each LU implementation has one or more pro- 
gramming environments that provide these 
functions. Each such environment is called 
an applications programming interface (API). 


The LU actually presents a partitioned proto- 
col boundary to the transaction program; for 
example, there are separate subsets of the 
verbs for mapped conversations, for basic 
conversations, and for SNA/DS. When a 
hierarchical relationship exists between 
these subsets, e.g., when verbs from one set 
cause internal issuances of verbs from anoth- 
er set, this partition introduces sublayers 
within the LU. 


A protocol boundary can be interpreted from 
two points of view. 


From one point of view, a protocol boundary 
is a boundary between two layers or sublayers 
of the node. For example, TPs exchange data 
with LUs across the TP-LU protocol boundary, 
and LUs exchange data with the path control 
network across the LU-path-control protocol 
boundary. From this viewpoint, the rules of 
exchange define protocols between adjacent 
layers. 


But from another point of view, a protocol 
boundary is a boundary between two paired (or 
peer), but distributed, components of the 
same layer. In other words, the transaction 
program protocol boundary may be thought of 
as a direct boundary between one TP and 
another, and similarly, the path control pro- 
tocol boundary may be regarded as a direct 
boundary between LUs. 


Figure 2-2 on page 2-5 shows the principal 
protocol boundaries between the LU = and 
external components. The figure illustrates 
how the protocol boundaries divide the LU 
into layers and sublayers, and how the con- 
ceptual flows between peer components are 
accomplished by successive adjacent-layer 
exchanges. In this example, the application 
TP has a mapped conversation with another 
application TP and a basic conversation with 
a service TP. The figure illustrates that 
the conceptual information flow between peer 
components at each layer is reduced to con- 
ceptual information flow at the next lower 
layer by actual information flow between lay- 
ers and information § transformation within 
layers. For example, the conceptual mapped 
conversation connection is reduced to a basic 
conversation; each basic conversation is 
reduced to a session; and finally, the ses- 
sions are reduced to connections in the path 
control network (which itself performs fur- 
ther layer transformations that are not 


shown). 
NAMES 


The LU allows transaction programs to refer 


to its resources, such as other TPs and LUs 


~~ 


i ee ; 
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Figure 2-2. Exchanges between Paired Distributed Components and between Adjacent Layers 


and shared communication facilities, by 
installation-selected names. Thus, the pro- 
grams need not be concerned with implementa- 
tion and configuration details such as_ the 
actual network locations or transport charac- 
teristics. For example, when one transaction 
program invokes another, the invoking TP 
identifies the partner TP by a_ transaction 
program name, it identifies the partner LU by 
an LU name, and it identifies the desired set 
of session characteristics by a mode name. 


Names are character strings that the instal- 
lation associates with particular resources. 
They are specified by the control operator 
(on behalf of the installation management) 
subject to the SNA-imposed constraints, e.g. >» 
character set and length’ restrictions, 
described in SNA Transaction Programmer's 
Reference Manual for LU Type 6.2 (Within an 
LU implementation, the local resource names 
may differ from those that conform to SNA; 
for example, a program directory might use 
names of a different length or character set. 
In this case, the implementation always 
translates between its internal names and the 
SNA-conforming names that are used by trans- 
action programs or that are transmitted out- 
side the LU. ) 


The name of a particular resource is Known 
within a particular environment. Within this 
environment, the name of each entity of a 
particular class is unique, but the same 
entity might have different names in differ- 
ent environments. For example, each LU 


allows local aliases for remote resource 
names, so that local transaction programs can 
be made insensitive to name changes elsewhere 
in the network. Of course, the control oper- 
ator mus t change the LU's relevant 
name-translation tables whenever the remote 
names are changed. 


Roles 


Hereafter, the following terms are used to 
distinguish the roles of individual TPs and 
LUs of a pair. With respect to location, the 
term local means residing at the LU from 
whose perspective an activity is described; 
the term remote means residing at that LU's 
actual or potential session partner. With 
respect to a conversation, the source TP (or 
its LU) is the initiator of a conversation 
with the target TP (or its LU). 


Transaction Program References 


A source TP selects a target transaction pro- 
gram by its transaction program name (TPN) as 
defined at the source LU. In the simplest 
case, this is also the name of the TP as 
defined at the target LU. Optionally, howev- 
er, the source LU can allow the two names to 
be different, in which case it converts the 
TP-supplied name into the TPN recognized at 
the target LU. 
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A TPN alone does not uniquely identify a 
transaction program instance. If the number 
of target transaction program instances does 
not exceed its instance limit, the target LU 
creates a new transaction program instance 
for each Attach it receives; otherwise, the 
target LU queues the Attach to await the 
freeing of a target transaction program 
instance. 


Lu References 


Each LU provides a set of LU names by which 
its TPs may refer to remote LUs: these names 
are called local LU names (a local LU name 
is a local alias of a remote LU's name, not 
the local LU's own name). Local LU names are 
unique within each LU, but not necessarily 
outside an LU. 


The control points involved in session initi- 
ation identify each LU by its 
network-qualified LU name This name consists 
of a network ID followed by a network LU 
name. The network ID is unique throughout a 
set of interconnected SNA networks; the net- 
work LU name is unique within a particular 
SNA network. 


The path control network routes information 
to an LU by a routing identifier rather than 
by a name. 


During session initiation, the LU supplies 
the network-qualified LU name to the control 
point. The control point provides a routing 
identifier for that network-qualified LU 
name. The correspondence between names and 
routing identifiers is established by the 
control point during session initiation. For 
more information on the relationship of LU 
names to routing identifiers (local-form ses- 
sion identifiers, or LFSIDs), refer to SNA 
Type 2.1 Node Reference. 


The LUs themselves use their 
network-qualified LU names for certain pur- 
poses; for example, LUs resolve some race 
conditions by exchanging and comparing their 
network-qualified LU names. 


Mode Names 


A source TP can specify that the session 
selected for a conversation have a particular 
set of characteristics, or mode. It does 
this by specifying a corresponding mode name. 


Mode names are shared between a given pair of 
LUs and are unique at an LU relative to a 
particular partner LU. Mode names for dif- 
ferent partner LUs are independent: the same 
mode name can correspond to different sets of 
session characteristics for different partner 
LUs. 
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Internal Identifiers 


The LU assigns internal identifiers to con- 
versations and sessions once they are acti- 
vated. 
half-session IDs, respectively. TPs or the 
control operator use these identifiers for 
subsequent references to these entities. 
These identifiers are generated by the LU and 
passed back to the transaction program or to 
the control operator in the form required for 
subsequent verbs; the transaction program or 
operator need not interpret these identifi- 
ers. 


CONVERSATION CHARACTERISTICS 
Send/Receive Protocol 


The LU normally allows TPs to exchange data 
in only one direction at a time, i.e., one TP 
sends and the other receives until the send- 
ing TP surrenders the right to send. This is 
called half-duplex flip-flop protocol. The 
LUs coordinate and enforce the send/receive 
state at each end of the conversation. LUs 
do allow some exceptions to strict alter- 
nation of send and receive: the receiving 
TP, at any time, can send an error indi- 
cation, putting itself in send state; it can 
send the partner an attention indication, 
e.g.» to request the right to send; and it 
can abnormally terminate the conversation. 


Sender/Receiver Concurrency 


applications require different 
of concurrency between sender and 
For example: 


Different 
degrees 
receiver. 
¢ On-line inquiry applications might 
require real-time interaction. 


applications might 
immediate transmission but no 


e Status-reporting 
require 
response. 


e Document distribution applications might 
allow sending and receiving at the send- 
er's and receiver's convenience, respec- 
tively, which might be separated by 
arbitrary periods of time. 


For the first two cases, the LUs use direct 


conversations between the TPs. 


For the real-time interactive case, the LU 
keeps the TP-TP connection active until the 
transaction is completed; both the source and 
target TPs are concurrently active. This is 
called synchronous transfer. 


The LU treats the immediate-transmission, 
no-response case as a special case of syn- 
chronous communication, using a one-way con- 
versation. The source LU allocates 
(initiates) a conversation as in the first 
case, sends the data, and deallocates (re- 


These are called resource IDs and- 


a 


CO) 


leases) the conversation. When the message 
reaches the target LU, it initiates the tar- 
get TP, which receives the data and likewise 
deallocates the conversation. But since the 
source TP is expecting no reply, it might 
have terminated while the data is still in 
transit through the path control network, 
before the target TP is initiated. Thus, the 
source and target TPs are not necessarily 
active at the same time. 


For the third case, the LU provides SNA Dis- 
tribution Services (SNA/DS). In this case, 
the sender, called the origin TP, and the 
ultimate receiver, called the destination TP; 
are typically not active at the same time. 
Therefore, the data is stored at one or more 
locations en route between periods of active 
transmission. This mode of communication is 
called asynchronous transfer. 


In SNA/DS, the origin application TP sends a 
message unit, ultimately intended for the 
destination TP, to a local service TP. The 
service TP at the origin stores the data in 
local permanent storage. When the appropri- 
ate time for sending the data arrives, e.g.> 
when lower-cost transmission facilities 
become available or after compensating for 
time-zone differences, a service TP at the 
origin allocates a conversation to a service 
TP at the destination and sends the data. 
The receiving service TP at the destination 
LU stores the data in local permanent storage 
for later retrieval. Finally, an application 
TP at the destination retrieves the stored 
message. 


SNA/DS also allows multiple intermediate 
service TPs between origin and destination. 
The origin service TP can allocate a conver- 
sation to an intermediate service TP, which 
would receive the data, store it», and later 
forward it to another intermediate service TP 
or to the ultimate destination service TP. 


Each SNA/DS service TP can also duplicate the 
data and send it to multiple destinations or 
application programs. 


Mapping 


Two communicating TPs might process the same 
information using different internal data 
formats (presentation spaces), e.g., differ- 
ently organized data structures or different 
sets of individual structures and variables. 
To assist the TPs in interpreting data in 
formats suited to their internal processing 
algorithms while providing a mutually under- 
stood format for the data transmitted over 
the conversation, some LUs' provide’ an 
optional function of mapped conversations,» 
called mapping. (Mapping concepts are dis- 
cussed in "Mapping Function" on page 2-36. ) 


SESSION ALLOCATION 


A principal function of the LU is to provide 
sessions between LUs for use by conversations 


between TPs. 


Session Multiplicity 


Only one transaction-program pair at a time 
can use a particular session. In order to 
allow multiple concurrent transactions, e.g. ,» 
for a multiprogrammed processor or a 
multiple-user workstation, some LUs, called 
parallel-session LUs» allow two or more ses- 
sions with a given partner LU. Any session 
between a pair of LUs that both provide par- 
allel sessions is called a parallel session; 
even if only one such session is currently 
active. 


Some LUs, called single-session LUs, allow 
only one active LU-LU session with a given 
partner LU. A _ single-session LU may have 
more than one session concurrently, but each 
concurrent session is with a different part- 
ner. Any session involving a single-session 
LU is called a single session, whether the 
other partner is a single-session LU or a 
parallel-session LU. 


Thus, all sessions between a pair of LUs are 
of the same type: single or parallel. Some 
LU protocols used on single sessions are dif- 
ferent from those used on parallel sessions, 
but these differences are indistinguishable 
to transaction programs. 


Session Pool 


To avoid repeating session-activation proc- 
essing for each conversation between the same 
pair of LUs, the LU allows successive conver- 
sations to use the same session. 


When the LU activates a session or when a 
session previously in use by a conversation 
becomes free, the LU places the session ina 
session pool. When ae transaction program 
initiates a new conversation, the LU allo- 
cates a session from this pool, if one is 
available. 


Session Selection 


Transaction programs do not select particular 
sessions, but specify only that the conversa- 
tion be allocated a session with a particular 
partner LU and with a particular mode name. 
The LU partitions the session pool by partner 
LU and mode name; the LU allocates a session 
from only those sessions for the requested 
(LU,mode) pair. 


Session Contention Polarity 


Another session-selection criterion concerns 
the relative priority of the LU for use of 
the session. The LUs at each end of a ses- 
sion could both try to start a conversation 
at the same time. To resolve this con- 
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tention, the LU operator specifies, for each 
session, which LU's TP will be allowed to use 
the session in such a case; this is called 
the session contention polarity. From the 
viewpoint of the local LU, a session for 
which that LU is designated to win an allo- 
cation race is_ called a_ contention-winner 
session (also referred to as a conwinner or a 
first-speaker session). A session that the 
local LU will surrender to the partner is 
called a contention-loser session (also 
referred to as aconloser or aeé bidder 
session--so called because a contention-loser 
LU will bid, i.e., request permission of the 
contention-winner LU to use the session). 


Session Limits 


The number of sessions in the session pool is 
constrained by operator-specified criteria, 
including several limits on the number of 
active sessions. 


The total LU-LU session limit is the maximum 
number of sessions that can be active at one 
time at the LU. 


The (LU,mode) session limit is the maximum 
number of LU-LU sessions that can be active 
at one time at an LU for that particular 
(partner LU,mode) pair. 


The automatic activation limit for a partic- 
ular (LU,mode) pair specifies the maximum 
number of LU-LU sessions that the LU will 
activate independently of requests for con- 
versations. Automatically activated sessions 
constitute the initial session pool (addi- 
tional sessions, within the other limits, are 
added to the pool on demand from conversation 
requests). 


The local-LU minimum contention-winner limit 
for a particular (LU,mode) pair determines 
the minimum share of the total number of ses- 
sions for that (LU,mode) for which the local 
LU can be contention winner. Similarly, the 
partner-LU minimum contention-winner limit 
determines the minimum share of those ses- 
sions for which the partner LU can be con- 
tention winner. 


Session limits are discussed in "Chapter 5.4. 
Presentation © ' Services--Control-Operator 
Verbs" in more detail. 


STARTING AND ENDING SESSIONS 


Phases 


Starting and ending sessions involves four 
phases of activity, although some phases are 
omitted in some circumstances. 


' Session-limit initialization and reset con- 


sists of control-operator verbs 
(e.g.> INITIALIZE_SESSION_LIMIT> 
RESET SESSION LIMIT) to specify the number of 
sessions the LU can have with a given part- 
ner, and to specify conditions for their 
activation and deactivation. 


1ssuling 


Session initiation and termination consists 
of control-point activity, such as supplying 
the network addresses corresponding to LU 
names, that mediates requests for session 
activation and deactivation. 


Session shutdown consists of the LU activity 
to terminate conversation activity on a ses- 
sion prior to deactivating the session. 


Session activation and deactivation consists 


of creating or destroying the end-to-end log- 
ical connection between the LUs.* 


SESSION USAGE CHARACTERISTICS 


Session Activation Polarity 


An LU activates a session with its partner by 
sending a message unit called BIND. The LU 
that activates a session (sends BIND) is 
called the primary LU (PLU); the LU that 
receives BIND is called the secondary LU 
(SLU). These terms are relative to a partic-— 
ular session: the same LU can be primary LU 
for one session and secondary LU for another. 


The primary LU always has first use of the 
session, 1.e., it can initiate the first con- 
versation on the session, regardless of the 
session contention polarity. (When the first 
conversation completes, the principal right 
to initiate conversations reverts to the 
contention-winner LU. ) 


Session-Level Pacing 


To prevent an LU from sending data faster 
than the receiving LU can process it (e.g., 
empty its receive buffers), the two LUs 
observe a session-level pacing protocol. At 
the time a session is activated, the LUs 
exchange the number (the pacing window size) 
and size (the maximum RU size) of the message 
units they can accept at one time. The send- 
ing LU will send no more message units than 
the receiver will accept (a pacing window) 
until the receiver sends an acknowledgment 


(pacing response) indicating that it can 
receive another pacing window. The pacing 


window size may be fixed for the duration of 
the session or varied adaptively in accord- 
ance with load and path congestion condi- 
tions. (For more information on pacing refer 
to "Chapter 6.2. Transmission Control") 


1 Session shutdown protocols use data flow control RUs, e.g.» BIS. 
Session activation and deactivation protocols use session control RUs, e.g.» BIND, UNBIND. 
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) 


Figure 


heal 


Profiles 


Session traffic is characterized by a partic- 
ular set of SNA-defined formats and proto- 
cols, identified by a function management 
(FM) profile and a transmission services (TS) 


profile (see SNA Formats). The profile used 
depends on the Kind of session and the kind 
of node: FM profile 19 and TS profile 7 are 
used by LU 6.2 for LU-LU sessions. 


Primary LU Secondary LU 
BIND (RD1) 
1 oe 
RSP(BIND, PWERD1], RD2) 
2 < Oo 
r UNBIND 
3a | oO 
| 
--or--< 
| FMH-12 (PWERD21) 
3b [ o> 
L 
r UNBIND 
4a [ < o 
| 
--or--< 
| 
4b | 
L 
LEGEND: 
RD1i random data (1=1/2) 
PW LU-LU password 


PW[IRDi] RDi enciphered using PW as cryptography Key 


2-3. LU-LU Verification 
SECURITY 


The LU provides three functions to assist the 
installation in providing security: partner 
LU verification, partner end-user verifica- 
tion, and session cryptography. Partner-LU 
verification is a session-level security pro- 
tocol; it involves protocols at the time the 
session is activated. Partner end-user ver- 
ification is a conversation-level security 
protocol, taking place at the time a conver- 
sation is started. Session cryptography is 
another session-level protocol, the parame- 
ters for which are exchanged at session acti- 
vation. 


Partner-LU verification is done by a 
three-flow exchange between the two LUs, with 
each LU using an LU-LU password and the Data 
Encryption Standard (DES) algorithm. This 
exchange is called LU-LU verification. LU-LU 
passwords (see SNA Transaction Programmer's 
Reference Manual for LU Type 6.2) are estab- 
lished by = implementation and 
installation-defined methods outside of SNA. 
LU-LU passwords are on a partner-LU basis: 
one LU-LU password is established between 
each LU pair. This password is used for all 


sessions between the LU pair. It is recom- 
mended that each LU pair have a unique pass- 
word; however, it is not an architectural 
requirement. 


Figure 2-3 shows the LU-LU verification pro- 
tocol exchanges. In the following dis- 
cussion, the numbers in parentheses 
correspond to the numbers in that figure. 


During session activation, random data (RD1) 
is sent in BIND from the primary LU to the 
secondary LU (1). The secondary LU enciphers 
this random data using the LU-LU password and 
the random data as input to the DES algo- 
rithm. The secondary LU returns (2) the now 
enciphered random data (PWIRD1]) to the pri- 
mary LU along with its own randomly generated 
data (RD2) in RSP(BIND). The primary LU com- 
pares the received enciphered random data 
with its own copy of the random data that it 
enciphered using its LU-LU password and the 
DES algorithm. If the two versions of the 
enciphered random data do not compare equally 
(3a), LU-LU verification fails, session acti- 
vation fails, and a security violation is 
logged. If the two versions of the enci- 
phered random data compare equally (3b), the 
primary LU has verified the identity of the 
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secondary LU and LU-LU verification contin- 
ues. 


Using the LU-LU password and the DES algo- 
rithm, the primary LU enciphers the random 
data received from the secondary LU. The 
primary LU returns this enciphered random 
data (PWIRD2]) in a Security FM header 
(FMH-12) to the secondary LU (3b). The sec- 
ondary LU compares this enciphered random 
data with its own version of the enciphered 
random data. If the two versions of the 
enciphered random data do not compare equally 
(4a), LU-LU verification fails, the session 
is terminated, and a security violation is 
logged. If the two versions of the enci- 
phered random data compare equally (4b), the 
secondary LU has verified the identity of the 
primary LU, and LU-LU verification is com- 
plete. 


When the transmission links and LUs that make 
up the network are physically secure (as 
determined by the installation management), 
LU-LU verification may be omitted. Under 
this circumstance, LU-LU verification would 
not take place, yet the session would still 
be considered secure; therefore, access to 
secure resources would still be permitted 
following conversation-level security proto- 
cols (see below). Permission to use 
conversation-level security to gain access to 
secure resources is installation defined and 
communicated to the partner LU during session 
activation in the BIND/RSP(BIND) exchange. 


When the network is not considered secure, 
LU-LU verification should be omitted, and 


access to secure resources via 
conversation-level security should not be 
permitted. Denial of permission to use 


conversation-level security is installation 
defined; an indication of this denial is com- 
municated to the sender of the request during 


session activation in the  BIND/RSP(BIND) 
exchange. 
End-user verification (conversation-level 


security) is used to confirm the identity of 
the partner end user (e.g., transaction pro- 
gram). When a TP requests access to another 
TP, it must supply adequate security informa- 
tion in the request to satisfy the security 
requirements of the requested TP, or the 
request will be rejected. This could include 
a user ID and password (see access security 
information subfields in SNA Formats) sup- 
plied by the end user that initiated the 
request. When a user ID and password are 
supplied on the request, they are verified by 
the LU that receives them. If the end user 


has not supplied the correct user ID and 
password combination, the request is 
rejected. 


An optional additional criterion for access 
to a specific TP is permitted. This criteri- 
on would be a check of an authorization list 
associated with the target transaction pro- 
gram. The Keys to search the authorization 
list would be combinations of the user ID and 
an optional profile supplied on the request; 
along with the name of the partner LU from 
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which the request originated. The authori- 
zation list could be made up of combinations 
of user ID, profile, and partner LU name. 
After the user ID is verified by the LU, the 
authorization list may be searched for access 
rights to the specific transaction program 
named in the request. If the additional cri- 
terion is not met, the request is rejected. 

transaction 


An intermediate program (one 


started by another TP) that requires 
conversation-level security may need_ to 
access ane additional TP that = requires 


conversation-level security. In this case, 
an Already Verified indicator is set in the 
additional request; the user ID and optional 
profile in the first request, which initiated 
the intermediate transaction program, are 
supplied in the second request. For security 
reasons, the password that initiates the 
intermediate TP is never saved, but the user 
ID and optional profile that initiated the 
intermediate TP are’saved. The Already Veri- 
fied indicator can be used only if the sender 
of the indicator is trusted by the receiver 
of the indicator to have performed the proper 
verification of the user ID and password that 
initiated the sender. This level of trust is 
installation defined at the receiver of the 
indicator and communicated to the sender of 
the indicator during session activation in 
the BIND/RSP(BIND) exchange. 


To help prevent data from being interpreted 
or modified during transit, the LU provides 
session cryptography, whereby all user data 
1s enciphered at the source LU and deciphered 
at the target LU. The encryption algorithm 
uses a cryptographic Key», supplied by the 
control point, and a session seed, generated 
by one of the LUs when the session is acti- 
vated. (See "Chapter 6.2. Transmission Con- 
trol" for ae full discussion of session 
cryptography. ) 


ERROR HANDLING 
Kinds of Errors 


Errors affecting transaction processing are 
classified as follows: 


Application Errors: These are errors related 
to the application data and processing» e.g. > 
user input error or data-base record missing. 
Detection and recovery are the responsibility 
of the transaction programs. 


Local Resource Failure: These are failures 
in non-SNA resources, e.g., a disk read 
error. If the resources are not protected 
resources, recovery is the responsibility of 
the transaction program or of the non-SNA 
support for the failing resource, e.g.» a 
disk subsystem. If the resource is a pro- 
tected resource, the TPs can use the LU sync 
point function (see "Sync Point Function" on 
page 2-37) to assist in recovery in conjunc- 
tion with non-SNA support. 
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Recoverable System Errors: These are errors 


or exceptional conditions, e.g.» races 
resulting from contention for use of a ses-~ 
sion, for which an SNA-defined recovery algo- 
rithm exists. The LU performs the recovery 
algorithm; the transaction programs = are 
normally not aware of these errors, except as 
they affect timing. 


Program Failures: These are errors’ that 
cause abnormal termination of a transaction 
program. The LU recovers from such errors by 
deallocating any active conversations for the 
TP that were not deallocated by the failed 
transaction program, thus freeing the ses- 
sions for use by other transaction programs. 
Any further recovery depends on transaction 
program logic and = implementation-defined 
capabilities such as error exits. 


Session Failure: These are failures caused 
by unrecoverable failure of the 
half-sessions,» e.g.» invalid session proto- 
cols received, or by failure of the underly- 
ing network components, e.g.» the links. 
This case is reported to the LUs through ses- 
sion outage notification (SON). 


If a conversation is active on the session at 
the time of failure, the failure is mani- 
fested to the transaction program as a con- 
versation failure (see below); otherwise, 
these errors do not affect transaction pro- 
grams. LUs report the conversation failure 
to the affected transaction programs. 


Conversation Failures: These are failures 
caused by unrecoverable failure of the under- 
lying session. The resulting conversation 
failure is reported to each transaction pro- 
gram by a return code on a subsequent verb. 
The same session and conversation cannot be 
recovered, but the LU can activate another 
session. 


The operator or the transaction programs have 
the responsibility to recover the’ trans- 
action. To recover from an interruption in 
transaction processing, for example, the 
source transaction program can allocate a new 
conversation, using another session, to a new 
instance of the target transaction program or 
to another transaction program. 


LU Failure: This is a failure of an LU from 
such causes as malfunction of the implement- 
ing hardware or software. In many cases, 
such a failure appears to remote 
(non-failing) LUs as a session failure, and 
they recover as they would from any other 
session failure. In some cases, recovery is 
performed by the sync point function. 


Program Error Recovery Support Functions 


The LU assists TP recovery from application 
errors and local resource failures by sup- 
porting the protocols discussed below to 
exchange error information and to immediately 
end messages or conversations. 


Confirmation: This function (e.g., CONFIRM 
verb) allows a TP to solicit positive or neg- 
ative acknowledgment of a message unit from 
the partner TP. The interpretation of this 
positive or negative acknowledgment (CON- 
FIRMED or SEND_ERROR verbs, respectively) is 
program dependent: for one application, con- 
firmation might mean only that the data was 
received; for another, it might mean data was 
safely stored on disk; for a third, it might 
mean that the data represents a valid account 
record update; and so forth. 


Program Error’ Indication: This function 
(SEND_ERROR verb) allows a TP to inform the 
partner TP of a program-detected error; this 
includes sending negative acknowledgment to a 
confirmation request. 


This function also causes program-to-program 
transfer of the current message unit to 
cease. If a TP detects an error while 
receiving» issuing the  SEND_ERROR- verb 
directs the receiving LU to ignore any addi- 
tional data in transit (1.e., to the end of 
the conversation message--see "Conversation 
Message" on page 2-14); this is called purg- 
ing. Similarly, if a sending TP detects an 
error, issuing the SEND_ERROR verb informs 
the partner that the source TP has stopped 
sending. If the TP stops sending before 
reaching a predetermined application-program 
data boundary (1.e., the end of a_ logical 
record--see “Logical Record" on page 2-13), 
this is called truncation. 


Sync Point: Many transactions require con- 
sistent, regular updates of distributed 
resources such as distributed data bases. 
While a transaction is in progress, however, 
the resources at different LUs can enter 
mutually inconsistent interim states. If one 
of the transaction programs encounters an 
error, some recovery action may be necessary 
to restore the resources to mutually consist- 
ent states. In order to verify or restore 
consistency among distributed resources, some 
LUs provide ae distributed error-recovery 
function, called sync point. (Sync point 
concepts are discussed in "Sync Point Func- 
tion" on page 2-37.) 


Abnormal Conversation Deallocation: This 
function allows a TP to abnormally terminate 
a conversation. A TP might do this, for 
example, when an error is detected for which 
it has no recovery procedure and continuing 
the transaction would be meaningless. When 
this is received, the LU informs the TP that 
the conversation has been abnormally termi- 
nated. 


When a component of the LU (e.g., an LU serv- 
ice TP) abnormally terminates a conversation 
that 1s being used by a TP, the LU uses DEAL- 
LOCATE TYPE(ABEND_SVC) to terminate the con- 
versation. This allows the TP and its 
partner TP to distinguish between 
application-generated and LU-generated abnor- 
mal terminations. 
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LU Error Recovery Functions--Abnormal Session 


I CES eC = SRST EES 


Deactivation 


For some errors, the LU or operator initiates 
recovery. 


If an unrecoverable session-protocol error 
occurs, the LU abnormally deactivates the 
session. 


If the control operator detects an error, 
@.g.» an apparent deadlock or loop, it can 
force immediate abnormal deactivation of a 
session. 


Either of these cases are normally manifested 


to affected transaction programs as conversa- 
tion failure. | 


BASE AND OPTIONAL FUNCTION SETS 


The LU functions and protocols are organized 
into subsets. The function sets consist of a 


base function set, which provides basic com- 


munication services common to all LU imple- 
mentations, and a small number of optional 


function sets, which may be used by implemen- 


tations with more sophisticated additional 
requirements. These SNA-defined function 
sets are described in SNA Transaction Pro- 


grammer's Reference Manual for LU Type 6.2. 


All LU 6.2 implementations of a given func- 
tion set provide that function in a way that 
conforms to the protocol boundary. Further- 
more, an LU 6.2 implementation that provides 
one function in an option set provides all 
other functions in that option set as well. 
Thus, all LU 6.2 implementations can communi- 
cate using the base set, and any two imple- 
mentations supporting functions in the same 
option set can communicate using that full 
option set. | 


Two Kinds of optional functions exist. Send 
options determine what formats and protocols 
will be sent but do not affect what can be 
received; all formats and protocols sent 
using these options can be received by all 
LUs. Receive options determine what can be 
received as well as what can be sent. For 
receive options, the source LU and “TP 
requirements are described in the BIND and 
the Attach; the receiving LU rejects the ses- 
sion or conversation if it, or the specified 
TP, does not support the required options. 


All implementations of LU 6.2 include the 
functions described in this book in their 
entirety except were options are specifically 
defined. For additional definition = of 
options see SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2. The principal 


Application Program Interface Implementations 


Open-API implementations support arbitrary 
user-written transaction programs, e.g.» a 
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data-base management system running on a host 
processor. For these implementations, the 
API provides verbs and parameters for all of 
the base function set, and perhaps some 
optional function sets. 


Closed-API implementations do not = support 
user-written programs but provide only a 
fixed, implementation-determined set of serv- 
ice transaction programs, e.g.» a DIA service 
transaction program for an office work- 
station. For these implementations, the API 
provides only the particular verbs and param- 
eters that the transaction program. set 
requires. 


Principal Base Functions 


Basic Conversations: All implementations 
provide receive support for all 


basic-conversation formats and protocols. 


Open-API implementations provide basic con- 
versation verbs, but not necessarily in all 
supported programming languages. For exam- 
ple, an implementation might support both 
basic- and mapped-conversation verbs in a 
systems-programming language such as Assem- 
bler, but provide only mapped-conversation 
verbs in high-level languages. 


Mapped Conversations: All open-API implemen- 
tations provide mapped conversations (prima- 
rily in high-level languages). 


Principal Optional Functions 


Mapping: This is an optional function for 
mapped conversations (see "Mapping Function" 
on page 2-36). 


Sync Point: This is an optional function for 
basic and mapped conversations (see "Sync 
Point Function" on page 2-37). 


Program Initialization Parameters (PIP): 
This is the means of passing initial parame- 
ters or environment setup information to a 
target TP. 


Security: This is an optional function for 
verifying the identity of partner LUs and end 
users (see “Security"™ on page 2-9), and for 
protection of data in transit. 


Performance Options: Several optional func- 
tions exist to maximize performance for spe- 
cific transaction requirements. For example, 
an LU can optionally allow transaction pro- 
grams to eliminate or accelerate certain 
acknowledgments, or to perform processing 
concurrently with certain conversation func- 
tions. These are send options, so TPs writ- 
ten for implementations that support these 
options will operate correctly with partner 
TPs and LUs that do not support them. 


CO 


MESSAGE UNITS AND THEIR TRANSFORMATIONS 


A message unit (MU) is any bit-string that 
has an SNA-defined format and is transferred 
between SNA components or sublayers. 


Distributed transaction programs exchange MUs 
with each other by means of LUs. Transaction 
programs exchange application-oriented units 
of data, e.g.» a customer record or a docu- 
ment, over a conversation. The LUs, in turn, 
exchange  session-oriented MUs- via the 
path-control network. But the content and 
format of an MU most appropriate for exchange 
between transaction programs is in general 
different from that most appropriate’ for 
transmission on a session. Whereas an appli- 
cation program typically uses a record size 
corresponding to logical groupings of the 


data, the LU typically uses MU sizes related 


to internal buffer sizes and efficient flow 
control. Furthermore, the LU may need to add 
encoded protocol information, such as confir- 
mation requests or MU sequence numbers, to 
the program-supplied data. 


The LU transforms program-oriented MUs used 
by the TP into network-oriented MUs used by 
the path control network, and vice versa. 
(Throughout this section, message-unit tran- 
sformations are described from the sender's 
side, 1.e., transaction program to LU to net- 
work; the process is inverted at the receiv- 
er.) 


The message-unit transformation takes place 
in stages. Each stage transforms some of the 
information from the higher stage into a 
SNA-defined bit string. Typically, a stage 
reblocks (regroups) the MUs from the previous 
stage into differently sized units and con- 
verts the protocol information into formatted 
headers (prefixes) to the reblocked data, 
thus creating new MUs. 


MAPPED-CONVERSATION MESSAGE UNITS 


A data record, at the mapped-conversation 
protocol boundary, is a collection of data 
values that correspond to the DATA parameter 
of a single mapped-conversation MC_SEND_DATA 
verb issuance. The format of a data record 
is completely arbitrary within the con- 
straints of the implementation and the trans- 
action program. For example, it need not 
even be a contiguous byte string, but might 
be a collection of variables and structures. 


A mapped-conversation record (MCR) is the 
elementary unit of information transferred 
between two TPs on a mapped conversation. A 
MCR contains the values of a data record 
represented as a string of contiguous bytes. 
It may be of arbitrary length. It contains 
no information for use by the LU; its 
internal format is significant only to the 
TP. The TP supplies needed protocol informa- 
tion, such as the mapped-conversation record 
length, in separate parameters of the verb, 


using representations appropriate to the pro- 
gramming language and processor being used. 


(A MCR consists of data from a single verb 
issuance by the sender, but it may be 
received in one or more parts, each with a 
single verb issuance, depending on the 
receiving TP's receive buffer size). 


BASIC-CONVERSATION MESSAGE UNITS 
GDS Variables 


Full connectivity among programs requires 
that all transaction programs interpret the 
records they transfer in the same way. To 
facilitate uniform interpretation of records 
among programs written for different process- 
ors, service transaction programs and some 
internal LU components » including 
mapped-conversation support, use the formats 
defined by general data stream architecture 
to represent records (see SNA Formats ) 


A general data stream (GDS) variable consists 
of a GDS header (LLID) followed by the data. 
The GDS header is a descriptive prefix con- 
taining a 2-byte length prefix (LL) that 
indicates the length of the variable, includ- 
ing prefix, and a format identifier called 
the GDS ID that indicates the GDS-defined 
format of the data. The LLs identify the 
boundaries of variable-length fields within a 
message unit of contiguous fields, and the 
GDS IDs identify the representation of the 
data. A GDS variable may be of arbitrary 
length. If the variable length exceeds the 
value that can be represented in the length 
prefix (215-1 = 32,767 bytes, including the 
prefix), the record consists of multiple seg- 
ments, each with its own length prefix. Only 
the first segment contains an ID field. The 
length prefix also contains a_ continuation 
bit that indicates whether the corresponding 
segment is the last (or only) segment in the 
GDS variable. 


All data transferred at the 
basic-conversation protocol boundary by serv- 
ice TPs and other internal LU components (but 
not necessarily data transferred by applica- 
tion transaction programs) is represented as 
GDS variables with SNA-defined formats (see 
SNA Formats). 


Logical Record 


A logical record is the elementary unit of 
information transferred between users of the 
basic-conversation protocol boundary. A log- 
ical record consists of a 2-byte length pre- 
fix (LL) followed by data. Its maximum 
length is 32,767 bytes, including the prefix. 
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The LL prefix of a logical record has the 
same format as the LL field in a GDS variable 
segment; thus, a GDS variable segment is also 
a logical record. The basic-conversation 
protocol boundary requires only the LL pre- 
fix, not a full GDS LLID. Thus, logical 
records generated by application TPs: need not 
use ID fields; if they do, the application 
assigns and interprets the ID fields; the 
basic-conversation support of the LU treats 
everything following the LL prefix of the 
logical record as user data. 


The logical record is the elementary unit for 
which the LU detects or reports truncation. 


Buffer Record 


It might be inconvenient for a_ transaction 
program to issue a single send or receive 
verb for each logical record. For example, 
the sender or the receiver might have limited 
buffer space or might not Know ahead of time 
the maximum length of the records being sent. 
Or, the transaction program might prefer to 
send a group of small, related records with a 
single verb issuance. So, the unit of data 
that a program sends or receives with a sin- 
gle basic-conversation verb is of 
program-determined length. This unit is 
called a buffer record. 


No SNA-defined limit exists on the length of 
a buffer record; for example, it could exceed 
32,767 bytes. The buffer-record length can 
be different for each verb issuance. 


No correspondence is necessary between the 
lengths or boundaries of logical records and 
those of buffer records, or between send 
buffer records and receive buffer records. 
Nevertheless, a receiving program = may 
optionally specify that the LU begin a new 
receive buffer record for each new logical 
record received. The relationship between 
logical records and buffer records is illus- 
trated in Figure 2-6 on page 2-18. 


CONVERSATION MESSAGE-UNIT SEQUENCES 


Certain sequences of message units are rele- 
vant to conversation protocols. 


Conversation Message 


A basic-conversation message consists of the 
sequence of logical records transferred in 
one direction from one TP to another without 
an intervening change of direction or confir- 
mation. (The Attach FM header generated from 
the ALLOCATE verb is also considered part of 
the initial basic-conversation message. ) 


The end of a conversation message is deter- 
mined, when sending, by a conversation state 
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change caused by the verbs issued. For exam- 
ple, PREPARE_TO_RECEIVE, RECEIVE_AND WAIT, 
CONFIRM, SYNCPT, and DEALLOCATE end a conver- 
sation message. When receiving, the end of a 
conversation message and conversation state 
change is determined from corresponding pro- 
tocol information received from the sender. 
The information identifying the end of a con- 
versation message and specifying the way it 
was ended is generically called = the 
end-of-conversation-message indication. 


A basic-conversation message is the elementa- 
ry unit for which the LU supports confirma- 
tion or  program-error reporting (e.g.> 
SEND_ERROR) between sender and receiver, and 
for which it performs purging. 


A mapped-conversation message is analogous to 
a basic-conversation message; that is, it 
consists of the sequence of 
mapped-conversation records (or data records) 
transferred in one direction from one TP to 
another without an intervening change of 
direction or confirmation, as understood at 
the mapped-conversation protocol boundary. 


The unqualified term, conversation message,» 
is used when the intended protocol boundary 
is clear from the context, or when both the 
mapped-conversation message and its corre- 
sponding basic-conversation message are 
designated. 


Conversation Exchange 


A conversation exchange consists of the com- 
plete set of mapped- or basic-conversation 
messages transferred between a pair of TPs 
using a particular conversation. 


SESSION MESSAGE UNITS 


Session message units are formatted for LU-LU 
protocols and for effective use of the path 
control network. 


Function Management Headers 


A function management (FM) header is a mes- 
sage unit generated by the LU to carry cer- 
tain LU control information. The LU uses the 
following FM headers: 


e = An Attach FM header (FMH-5) specifies the 
name and required characteristics, e.g.» 
option sets required, of the target TP. 


e An Error-Description FM header (FMH-7) 
describes a transaction program error or 
Attach failure. 


e A Security FM header (FMH-12) carries 


security information for LU-LU verifica- 
tion. 


( 


—- 


——. 


*, ie 


Basic Information Unit 


A basic information unit (BIU) is the message 
unit transferred between two LUs. It con- 
sists of a request/response header (RH) and a 


request/response unit (RU). 


The RH is a formatted prefix to the RU. It 
carries protocol information encoded from the 
TP verbs or generated internally by the LU. 
It may also appear without an RU in an IPR or 
IPM. SNA Formats gives further details. 


Request RUs carry FM headers, TP-supplied 
data (formatted into logical records by the 
TP in basic conversations or by the LU in 
mapped conversations), and other’ protocol 
information. Response RUs_ carry limited 
information, such as the echoed request code 
or (in negative responses) sense data, but no 
TP-supplied data. 


The LU uses the following RUs on an LU-LU 
session: 


° Category FMD RUs, for transaction-program 
data 


e Category DFC RUs, i.e., BIS, LUSTAT> RTR> 
SIG, and their responses 


e Category SC RUs, i.e., BIND, UNBIND;, CRV, 
and their responses 


(For additional details, see SNA Formats. ) 


EXR also flows for some path-control-detected 
errors. 


The LUs also transfer other information 
describing the BIU, such as the length and 
sequence number, which is formatted by path 
control ina transmission header (TH). 


SESSION MESSAGE-UNIT SEQUENCES 


The following sequences of BIUs are relevant 
to session protocols: 


A (BIU) chain is a sequence of BIUs that con- 
stitute a single unidirectional transfer. 
The chain is the most elementary unit that 
can be independently confirmed or for which 
errors can be reported using SNA-defined LU 
protocols. It corresponds to a TP-TP conver- 
sation message. 


A bracket consists of the set of all chains 
transferred on a particular conversation. It 
corresponds to a TP-TP conversation exchange. 
The first data RU in a bracket begins with an 
Attach FM header that identifies the target 
TP. 


The total session traffic comprises a 
sequence of one or more brackets. Prior to 
bracket traffic, the session is activated 
(BIND protocols). Prior to normal session 
deactivation, bracket traffic is shut down 
(BIS protocols). All session traffic stops 


when the session is deactivated (UNBIND pro- 
tocols), whether or not any brackets are in 
transit. 


Figure 2-¢@ on page 2-16 illustrates the cor- 
respondence between the conversation 
message-unit sequences and session 
message-unit sequences. In the figure: 


¢ The column labelled TP-TP shows the con- 
versation message-unit sequences. 


(The corresponding conversation 
message-unit sequences for the partner 
TPs at LU Y are not shown; they are the 
reverse of those shown for TP A and TP 
B.) 


¢ The column labelled LU-LU shows the ses- 
sion message-unit sequences. 


e The column labelled LU xX _ shows’ the 
relationship between the two sets of 
sequences. 


MAPPED-CONVERSATION MESSAGE-UNIT TRANSFORMA- 
TION 


The mapped-conversation support in the LU 
converts a data record into a GDS variable. 


First, the LU optionally performs a 
TP-specified mapping transformation on the 
data record, producing a mapped-conversation 
record. If mapping transformations are not 
supported or if one is not specified, the TP 
supplies the data in MCR format (1.e., a con- 
tiguous byte string of TP-determined length). 


The mapped-conversation support in the LU 
then segments the MCR into units of allowed 
logical-record length and adds LLID prefixes; 
thus producing a GDS variable consisting of a 
sequence of logical records. This is illus- 
trated in Figure 2-5 on page 2-17. 


BASIC-CONVERSATION MESSAGE-UNIT TRANSFORMA- 
TION 


Above the basic-conversation protocol bounda- 
ry,» a TP, or an internal LU component such as 
the mapped-conversation support, generates a 
sequence of logical records constituting a 
conversation message. It passes this conver- 
sation message to the LU as a sequence of 
buffer records, by issuing basic-conversation 
verbs. Along with the buffer records, it 
passes unformatted protocol information such 
as the ALLOCATE verb parameters, from which 


‘the LU builds FM headers. 


Conceptually, the LU assembles the sequence 
of FM headers and logical records into a com- 
plete conversation message. It then converts 
this conversation message into a chain of 
BIUs. Of course, the LU does not necessarily 
store a complete conversation message at one 
time; when it accumulates enough buffer 
records to build one or more BIUs, it builds 
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those BIUs and sends them out, saving any 
residual data for the next BIU. 


To build BIUs, the LU reblocks the FM headers 
and logical records into RU-sized units and 
generates the necessary RHs. The LU sets the 
RH indicators to correspond to functions or 
states specified by verb parameters; for 
example, it sets the chaining indicators 
(BCI, ECI) to indicate the first and last 
BIUs in the chain, and it sets the bracket 
indicators (BB, CEB) to indicate the first 
and last BIUs in a bracket. When necessary, 
the LU also generates Attach or 
Error-Description FM headers (FMH-5 = and 
FMH-7) from verb parameters and includes 
these in the BIUs. The final result is a BIU 
chain. Along with the BIU, the LU generates 
parameter values for use by path control (to 
build the transmission header). The LU 
transfers the BIUs and the unformatted BIU 
parameters to path control for transmission 
to the partner LU. Figure 2-6 on page 2-18 
illustrates the conversion process. 


Relationship of Data Records to Logical Records (Example) 


DATA EXCHANGE WITH THE CP 


The LU also exchanges message units with the 
CP. These message units are listed in "Chap- 
ter 4. LU Session Manager" and are described 
briefly below. 


LU-CP Records 


In the model described in this book, the LU 
has a direct protocol boundary with the CP in 
its node. 


The LU generates and uses session control RUs 
for session activation and deactivation. It 
sends these to the CP for routing to the 
remote LU. 
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LR: logical record LL: Length field 
RH: request header RU: request unit 
FMH—-5: 


Attach values: 
TH values: 
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FLOW SEQUENCES FOR THE BASE FUNCTION SET 


This section illustrates the correspondence 
between some typical basic-function-set 
transaction program verb sequences and the 
resulting flows of BIUs through the path con- 
trol network. (The verbs are described in 
detail in SNA Transaction Programmer's Refer- 
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| <—__——- Blu ——_——_> | 
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GDS ID field 


basic information unit 


Attach FM header (occurs only on first conversation-message of conversation) 
information for the Attach FM header, from the ALLOCATE verb. 
protocol information generated by the LU; the TH is built by path control. 


Relationship of Conversation Message to BIU Chain (Example) 


The correspondence is illustrated in Fig- 
ure 2-7 on page 2-20 through Figure 2-23 on 
page 2-27. In the figures, the left column 
shows verbs issued by the invoKing or 
initially-sending TP, and the right column 
shows verbs issued in response by the invoked 
or initially-receiving TP. The center column 
shows the contents of the resulting chain (RH 
indicator settings, RU data and FM headers). 


C 


The arrows indicate direction of BIU flow. A 
group of arrows in the same direction repres- 
ents a chain, but no necessary correspondence 
exists between arrows in the figures and BIUs 
in the chain. 

Each figure shows one of the following: 


¢ The beginning of a chain, for chains that 
begin a bracket 


@ The end of one chain and the beginning of 
the next 


e The end of a chain, for chains that end a 
bracket 


“Allowable Combinations of Sequences" on page 
2-22 shows how these flows can be combined, 
or sequenced, to form complete conversations. 
Finally, “Error Flows" on page 2-24 shows 
asynchronous response cases. 

NOTATION 

The following notation is used in the fig- 


ures. RH indicators: 


The flow is labeled with the indicator values 
that are carried in the RH. 


BB Begin bracket 

CEB Conditional end of bracket 

BC Begin chain 

EC End chain 

RQE1 Request exception response 1 

RQE2 Request exception response 2 (in this 
case, DRII = DR1I-DR1; i.e., RQE3 is 
equivalent to RQE2). 

RQD1 Request definite response 1 

RQD2 Request definite response 2 (in this 
case,» DRII = DRII-DR1; i.e., RQD3 is 
equivalent to RQD2Z). 

CD Change direction 

+DR2 Positive response to RQD2 

-RSP(0846) Negative response to chain 

RU contents: 

FMH-5 Attach FM header 

FMH-7 Error-description FM header 
The sense-data categories shown are: 


0864 Abnormal deallocation 


0889 Program-detected error 


data User data in FMD RU 


Verbs and Parameters 


The returned RETURN_CODE parameter of the 
RECEIVE _AND_WAIT verb is not shown when it is 
set to OK; in that case, the returned 
WHAT_RECEIVED parameter is shown instead. 


DATA_* represents either setting (DA- 
TA_COMPLETE or DATA_INCOMPLETE) of this 
parameter. 


Data Transfer Description 


Whenever a TP has’ the right to send, it 
issues SEND_DATA zero or more times. Simi- 
larly, a TP in receive state repeatedly 
issues RECEIVE_AND_WAIT, until it receives 
all of the data and the 
end-of-conversation-message indication. The 
receiver issues at least one receive verb; in 
the absence of errors, zero or more initial 
issuances of SEND _DATA by the source TP 
result in zero or more receive verb issuances 
(with WHAT_RECEIVED = DATA_INCOMPLETE) at the 


target. The final issuance receives’ the 
end-of-conversat ion-message indicator as 
WHAT_RECEIVED = DATA_COMPLETE. Since the 


buffer record sizes used at the sending TP 
and at the receiving TP may differ, the num- 
ber of receive verb issuances does not neces- 
sarily match the number of send verb 
issuances. 


All of the following figures begin or end 
with the data-transmission sequence just 
described. That sequence is represented in 
the figures as follows. 


When the figure begins with (the end of) the 
data-transmission sequence, it shows (at the 
sending TP) a single SEND_DATA verb, and a 
corresponding data arrow, followed by verti- 
cal (two-dot) ellipsis marks (:). No 
RECEIVE_AND_WAIT verb is_ shown at the 
receiving TP. 


When the figure ends with (the beginning of ) 
the data-transmission sequence, it shows (at 
the receiving TP) vertical ellipsis marks 
(:), followed by a single RECEIVE_AND_WAIT 
verb with WHAT_RECEIVED = DATA_COMPLETE. 
"Data" is shown on the corresponding arrow, | 
along with the end-of-conversation-message RH 
indicators. No SEND_DATA verb is shown at 
the beginning of the receiving-TP verb 
sequence. 


ERROR-FREE FLOWS 


The error-free flows for the base function 
set flows are described in terms of the verb 
sequences shown in Figure 2-7 on page 2-20 
through Figure 2-14 on page 2-22. 
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SEQUENCE 1 


ALLOCATE 
SYNC_LEVEL(NONE ) BC >5BB,FMH-5 
> (TP started) 


SEND_DATA data 
> 


Figure 2-7. Start Conversation with Synchronization Level of NONE 


SEQUENCE 2 
PREPARE_TO_RECEIVE EC ,RQE1,CD,data RECEIVE AND_WAIT 
TYPE ( FLUSH ) —_—_— > _~—C WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE _AND_WAIT 
WHAT_RECEIVED=SEND 
BC data SEND_DATA 


Figure 2-8. Conversation Turnaround without Confirmation: PREPARE_TO_RECEIVE is optional; when it 
is omitted, and a receive verb is’ issued from SEND state, the function of 
PREPARE_TO_RECEIVE is performed before any data is actually received. 


SEQUENCE 3 
DEALLOCATE EC,RQE1,CEB,data RECEIVE _AND_WAIT 
TYPE( FLUSH ) ee WHAT_RECEIVED=DATA_COMPLETE 
(local deallocation) RECEIVE_AND_WAIT 
RETURN_CODE=DEALLOCATE_NORMAL 
DEALLOCATE 
TYPE( LOCAL ) 


(local deallocation) 


Figure 2-9. Finish Conversation without Confirmation 


SEQUENCE 4 

ALLOCATE BC,BB,FMH-5 
SYNC_LEVEL( CONFIRM )—————————_>. (TP started) 

SEND_DATA data | 


> 


Figure 2-10. Start Conversation with Synchronization Level of CONFIRM: The SYNC_LEVEL parameter on 
ALLOCATE establishes the synchronization level for the entire conversation. References 
to SYNC_LEVEL on subsequent conversation verbs refer to the SYNC_LEVEL value 
established at the start of the conversation. In this sequence, that value is CONFIRM. 
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aoe SEQUENCE 5 
| : : : 
= CONFIRM EC ,RQD2,-CD,data RECEIVE_AND_WAIT 
—— WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM 
+DR2 CONFIRMED 
RETURN_CODE=0K < 
SEND_DATA BC ,data 


Figure 2-11. Continue Conversation: Confirmation without Turnaround 


—. SEQUENCE 6A 
= PREPARE_TO_RECEIVE RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL) EC,RQD2,CD,data 
LOCKS( SHORT } $$$ > WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM_ SEND 
+DR2 CONFIRMED 
RETURN_CODE=OK $$$ 
BC ,data SEND_DATA 


Figure 2-12. Conversation Turnaround with SYNC_LEVEL = CONFIRM, using LOCKS(SHORT): When the 

receiving TP issues CONFIRMED after the LU has received RQD2--indicating CONFIRM 

& LOCKS(SHORT)--the LU immediately sends a CONFIRMED response (+DR2). This allows the 

eS CONFIRM sender to resume processing immediately, so that, for example, it can release 
locks on its local resources. 


(The receiving LU processes the RQD2 internally; it does not inform the receiving TP of 
the LOCKS parameter value. ) 


C. SEQUENCE 6B 
ae e . s 


PREPARE_TO_ RECEIVE : RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL) EC,RQE2,CD,data 
LOCKS( LONG) $$ $$$ > WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM_SEND 


CONFIRMED 
(LU omits sending +DR2) 
BC data SEND_DATA 
RETURN_CODE=OK ——— 

Figure 2-13. Conversation Turnaround with SYNC_LEVEL = CONFIRM, using LOCKS(LONG)}: When the 
receiving TP issues CONFIRMED after the LU has received RQE2--indicating CONFIRM 
LOCKS( LONG )--the LU does not send an immediate confirmation response. Instead, it 
continues processing until it has a complete BIU to send. The CONFIRM sender 


interprets receipt of BC without an intervening response as positive confirmation. 


LOCKS( LONG) does not require the +DR2 response BIU that LOCKS(SHORT) requires, but it 
can cause the CONFIRM sender to wait longer before resuming processing. 
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SEQUENCE 7 


DEALLOCATE EC ,RQD2,CEB,data RECEIVE AND _WAIT 
TYPE(SYNC_LEVEL ) > WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM_DEALLOCATE 
| +DR2Z CONFIRMED 
RETURN_CODE=OK << 
Local Deallocation DEALLOCATE 
TYPE( LOCAL ) 


Figure 2-14. 


ALLOWABLE COMBINATIONS OF SEQUENCES 


Finish Conversation, SYNC_LEVEL = CONFIRM 


either SYNC_LEVEL (NONE ) or 
SYNC_LEVEL(CONFIRM), 1.e.» conversa- 


Figure 2-15. Possible Next Sequence in Error-Free Cases 


2-22 


SNA LU 6.2 Reference: 


When a program issues one of the verb 
sequences shown above, that program is limit- 
ed in its choice of the next verb sequence it 
can issue. The matrix in Figure 2-15 shows 
which verb sequences can follow a given verb 
sequence in the base function set. The 
matrix has the following meaning: 


e The row numbers (left column) and column 
numbers (top row) in the matrix corre- 
spond to the sequence numbers in Fig- 
ure 2-7 on page 2-20 through Figure 2-14. 


A row corresponds to the verb sequence 
just issued; a column corresponds to the 
verb sequence issued next. 


In the matrix, row 0 or column 0 repres- 
ents the state in which no conversation 
exists, i.e., the state prior to ALLOCATE 
or subsequent to DEALLOCATE. 


© A letter N or C in a cell indicates that 
the sequence corresponding to the column 
number can follow the sequence corre- 
sponding to the row number. 


— N--indicates a next sequence allowed 


with 


for conversations allocated 


Peer Protocols 


tions started with sequences 1 or 4 


—- C--indicates a next sequence allowed 
only for conversations allocated with 
SYNC_LEVEL(CONFIRM), 1.e., conversa- 
tions started with sequence 4 


—-  empty--indicates that the correspond- 
ing sequence order is invalid 


e The Next-Sender column indicates which TP 
is initial sender (1.e., issues the verbs 
in the left column of the figure) for the 
next sequence: 


_ SAME--the initial sender of the next 


sequence is the same as the initial 
sender of the previous sequence. 


—- OTHER--the initial sender of the next 
sequence is the partner of the ini- 
tial sender of the previous sequence. 


Figure 2-16 on page 2-23 and Figure 2-17 on 
page 2-23 illustrate the application of these 
rules to generate allowable conversation 
sequences. 


6 
\ 
‘ 


c 
4 
? 
~~ ee 
~~ 


ALLOCATE 
SYNC_LEVEL(NONE ) BC ,BB,FMH-5 


> (TP started) 


SEND_DATA data RECEIVE_AND_WAIT 

> WHAT_RECEIVED=DATA_* 
SEND_DATA RECEIVE_AND_WAIT 
DEALLOCATE EC ,RQE1,CEB,data WHAT_RECEIVED=DATA_COMPLETE 


TYPE ( FLUSH ) 
(local deallocation) 


> RECEIVE_AND_WAIT 


DEALLOCATE 
TYPE( LOCAL ) 


RETURN_CODE=DEALLOCATE_NORMAL 


(local deallocation) 


Figure 2-16. One-Way Conversation without Confirmation: 


The sequence shown in Figure 2-16 is gener- 
ated as follows: 


1. Begin in state QO. 4. 


2. Select a column containing a lettered 


cell in row O. 


5 
In this example, column 1 was chosen. 
This corresponds to sequence 1. 

3. Supply an arbitrary number of SEND_DATA 

and RECEIVE_AND_WAIT verbs’ following 
sequence 1, as allowed by the the 
data-transfer convention. 

6. 
In this example, the ellipsis. was 


replaced by one additional issuance of 


ALLOCATE 


BC ,BB,FMH-5 


Combines Sequences 1 and 3 


SEND_DATA and one additional issuance of 
RECEIVE_AND_WAIT. 


Select a column containing an N in row 1. 
In this example, column 3 was chosen. 


Orient sequence 3 according to the "next 
sender" column for the previous sequence. 


In this example, the next sender is SAME, 
so the left column of sequence 3 is 
issued by the same TP as the left column 
of sequence 1. 


Select a column containing an N in row 3. 
The only choice is column 0, indicating 
the end of the sequence. 


SYNC_LEVEL( CONFIRM } 


>(TP started) 


PREPARE_TO_ RECEIVE EC,RQE2,CD RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL ) > | WHAT_RECEIVED=CONFIRM_SEND 
LOCKS( LONG ) CONFIRMED 

BC,data SEND_DATA 
RETURN_CODE=OK < 
RECEIVE_AND_WAIT 
WHAT_RECEIVED= EC ,RQD2,CEB,data DEALLOCATE 


DATA_COMPLETE < 
RECEIVE_AND_WAIT 

WHAT_RECEIVED= 

CONFIRM_DEALLOCATE 
CONFIRMED +DR2 

> RETURN_CODE=OK 

DEALLOCATE 

TYPE( LOCAL ) 


Figure 2-17. Two-Way Conversation with Confirmation: 


The sequence shown in Figure 2-16 1s gener- 2 
ated as follows: 


1. Beginning in state 0, select sequences 4, 
6B, and 7, returning to state O. 


TYPE(SYNC_LEVEL ) 


Combines Sequences 4, 6B, and 7. 


Supply some number of SEND_DATA and 
RECEIVE_AND_WAIT verbs following sequence 
4. 


In this example, 0 instances of SEND_DATA 
were chosen. Thus, following the data 
transfer convention, the SEND_DATA verb 
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and data arrow in sequence ¢ are elimi- 
nated, as is the RECEIVE _AND_WAIT 
WHAT_RECEIVED = DATA_COMPLETE and the 
data on the EC arrow in sequence 6B. 


3. The next sender following sequence 4 is 
SAME; therefore, sequence 6B has the same 
orientation as the preceding sequence. 


4. Supply some number of SEND_DATA and 
RECEIVE_AND_WAIT verbs following sequence 
6B. 


In this example, only one instance of 
each was chosen, corresponding exactly to 
the number in the sequence figures. 


(This figure illustrates that the arrows 
do not necessarily correspond to BIUs. 


For example, the CONFIRM, SEND_DATA> and 
DEALLOCATE might generate only one BIU, 
even though two arrows are shown in the 
figure. ) 


5. The next sender following sequence 6B is 
OTHER; therefore, sequence 7 is reversed 
to have the opposite orientation from 
that of the preceding sequence (i.e., 
since the left column of sequence 6B cor- 
responds to the left column of the com- 
bined sequence, the left colum of 
sequence 7 corresponds to the right col- 
umn of the combined sequence). 


6. The next row number is 03 therefore this 
completes the sequence. 


* 


5 . | fo ™* 
SEND_DATA data RECEIVE_AND_WAIT LD 
$$$ $$ > WHAT_RECEIVED=DATA_* 
SEND_DATA BC ,EC,SIGNAL (expedited flow) REQUEST _TO_SEND 
eS a eS ee 


REQUEST_TO_SEND_RECEIVED=YES RECEIVE_AND_WAIT 


PREPARE_TO_RECEIVE EC,RQE1,CD,data 
TYPE( FLUSH) -——-—-—-——-——"""""> WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=SEND 
RECEIVE _AND_ WAIT BC data SEND_DATA 
< 
WHAT_RECEIVED=DATA_* 
° aaa 
Figure 2-18. Conversation Turnaround following REQUEST_TO_SEND (without oo 
Confirmation): REQUEST_TO_SEND issued by the receiving TP results in an expedited-flow : 
one-RU chain. The TP sending data is notified via the REQUEST_TO_SEND_RECEIVED 
parameter of a subsequent verb. The interpretation of REQUEST_TO_SEND_RECEIVED is 


determined by’ the TP. 
RECEIVE_AND_WAIT. 


EXCEPTION FLOW 


Figure 2-18 illustrates the only non-error 
case for which a TP can send while in receive 
state. This flow represents issuing’ the 
REQUEST_TO_SEND verb and sending the SIGNAL 
RU. 


This flow can be substituted for sequence 2. 
A similar sequence corresponding to sequence 
6A or 6B exists, but is not illustrated here. 


ERROR FLOWS 


Figure 2-19 on page 2-25 through Figure 2-23 
on page 2-27 illustrate flows resulting from 
transaction-program error recovery for the 
base function set. When the TP detects a 
TP-defined error (e.g.» the received data 
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In this example, 


the sending TP stops sending and issues 


fails an application validity check, or the 
partner sends more logical records than 
expected) it issues SEND_ERROR or DEALLOCATE 
TYPE( ABEND). When the LU detects a trans- 
action program error, such as an Attach fail- 
ure, 1t generates similar flows. 

Three cases exist: 


®¢ Verb issued by sender 
® Verb issued by receiver 


e Verb issued by both (e.g., a SEND_ERROR 
race has occurred) 


(This case is not illustrated for DEALLO- 


CATE.) 
For cases not shown here, see "Component 
Interactions and Sequence Flows" on page 


2-48. 


\ /  SEND_DATA 
oe (TP detects RECELVE_AND_WAIT 
an error ) 
_ SEND_ERROR data 
$$ > WHAT_RECEIVED=DATA_INCOMPLETE 
SEND_DATA FMH-7( 0889 } data RECEIVE_AND_WAIT 
> WHAT_RECEIVED=PROGRAM_ERROR_TRUNC 


Figure 2-19. SEND _ERROR Issued by Sender: The SEND_ERROR verb forces sending of accumulated data 
and begins a new RU with an FMH-7. The issuing TP remains in send state; it can, for 
example, send additional TP-determined data to further describe the error. 


“.-s SEND_ DATA data RECEIVE_AND_WAIT 
+ —_—_—— OOO WHAT_RECEIVED=DATA_* 
(TP detects an error) 
-RSP (0846 } SEND_ERROR 


SEND_DATA data Purge incoming BIUs 
—_—__—_—_——_— | ———-—> to end of chain 


(LU ends chain) eae u 


EC,RQE1,CD,no data « 
— > " (LU detects end of chain) 
; RETURN_CODE=OK 
() BC » FMH-7( 0889 ),data SEND_DATA 
TD 


at RETURN_CODE= 
PROG_ERROR_PURGING 
RECEIVE_AND_WAIT 


Figure 2-20. SEND_ERROR Issued by Receiver: The SEND_ERROR verb causes a negative response to the 
incoming chain; the sending LU sends End-of-Chain and Change-Direction when it receives 
the response. Meanwhile, the receiver purges incoming RUs until the End-of-Chain 
indication is received, then it sends FMH-7 and leaves the issuing TP in send state so 
it can, for example,» send additional TP-determined data describing the error. 
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: , | < 
SEND_DATA data RECEIVE_AND_WAIT * 
$$ > | WHAT_RECEIVED=DATA_* | vv 

(TP detects an error) 


(TP detects —-RSP (0846 ) SEND_ERROR 
an error ) 
SEND_ERROR data Purge incoming BIUs 
———_—_—_—_—_—- | > to end of chain 
SEND_DATA FMH-7(0889),data “ 


> as 


(LU ends chain) joe| T 


EC,RQE1,CD,no data . 

——_—____________— > " (LU detects end of chain) 
RETURN_CODE=0OK 

BC ,FMH-7(0889),data SEND_DATA 
a i 

RETURN_CODE= 

PROG _ERROR_PURGING yoy 

RECEIVE_AND_WAIT - 


ee 
Figure 2-21. SEND_ERROR Issued by both Sender and Receiver (SEND_ERROR Race): Each LU begins 
SEND_ERROR processing as in the no-race case, but since the receiver is purging to end 
of chain, the SEND_ERROR from the sender is also purged, so the receiver's SEND_ERROR 
takes precedence. 

: : : AK 
SEND_DATA RECEIVE_AND_WAIT (~ : 
DEALLOCATE data Seer. 

TYPE( ABEND_PROG} —————__—_-_-> WHAT_RECEIVED=DATA_* 

EC,RQD1,CEB,FMH-7( 0864 ) RECEIVE _AND_WAIT 
$$ > RETURN_CODE= 
+DR1 DEALLOCATE_ABEND_PROG 
(response used <—————————_____——_— 
internally ) 
Figure 2-22. DEALLOCATE ABEND Issued by Sender: The flow is similar to SEND_ERROR in serd state. 
The +DR1 response is required for internal processing. 

c 
co 


ee 
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5 
7 


ee 


SEND_DATA data RECEIVE_AND_WAIT 
> WHAT_RECEIVED=DATA_* 
~RSP( 0846 ) DEALLOCATE 


TYPE ( ABEND_PROG ) 


SEND_DATA data Purging 
ciniainsanes eunsctirmceipuagasaGosapmaseaastcinaaa > au 
(LU ends chain) fear o 
EC ,RQE1,CD,no data aa 
> "(LU detects end of chain) 


Figure 2-23. 


BC ,EC ,RQD1,CEB,FMH~-7( 0864 ) 
<< 


RETURN_CODE= 
DEALLOCATE_ABEND_PROG 


+DR1 


> (response used internally) 


DEALLOCATE ABEND Issued by Receiver: 
state. 


LU STRUCTURE 


Figure 2-24 on page 2-28 illustrates the 
structure of the LU. 


The upper protocol boundary of the LU is the 
transaction program protocol boundary (de- 
scribed in SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2). A 
transaction program processes end user data, 
and requests LU services to communicate with 
other transaction programs. 


The lower protocol boundary of the LU is to 
the SNA path control network, which the LU 
uses to communicate with other LUs. 

The LU also has protocol boundaries with the 


CP, buffer manager, NOF, and with initiator 
processes in the same node. 


SNA LAYERS 
The LU contains instances of the following 
four SNA layers: 

Transaction services 

Presentation services 


Data flow control 


Transmission control 


Component Overview 


The LU has two groups of components, one for 
its upper protocol boundary with transaction 


The flow is similar to SEND_ERROR in receive 
The +DR1 response is required for internal processing. 


programs, and one for its lower protocol 
boundary with the path control network. Each 
group consists of a set of processes contain- 
ing a pair of SNA layer-instances, and a man- 
ager component that creates, destroys, and 
otherwise manages these instances. 


The upper group of components contains trans- 
action processes, which contain instances of 
the following SNA layers: 


Transaction services 
Presentation services 


More concretely, each transaction process 
contains an execution instance of a_ trans- 
action program and some presentation services 
components for processing the verbs issued by 
it. (See Figure 2-25 on page 2-29.) 


This group of components is managed by the 
resources manager component (RM), which cre- 
ates transaction processes (in response to 
Attaches received from remote LUs), destroys 
them after they have finished executing, and 
connects them with sessions (thus enabling 
them to participate in distributed trans- 
actions). 


The lower group of components’ contains 
half-sessions (HSs), which contain instances 


of the following SNA layers: 
Data flow control 
Transmission control 
Half-sessions enforce protocol rules for con- 


versation data exchange, and transform mes- 
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Transaction 


Program 


Resources 
Manager 


Session 
Manager 


Services Manager 


Presentation Services 


Control-— > Control Operator 


Operator 


Transaction 
Program 


A 
| 
| 
| | ti‘ 
6 
| e 
| | DIA e 
| SNADS | 
RESYNC 
| j & 
“ou 
| Service 
Transaction 
| Programs 
| 
V 
a 


V 
LEGEND: PATH-—CONTROL NETWORK 
< > Send/Receive relationship CP: Control Point IP: Initiator process 
<- - —> Call/Return relationship NOF: Node Operator Facility BM: Buffer Manager 
CNOS: Change Number of Sessions RESYNC: Syne Point Resynchronization 
SNADS: SNA Distribution Services DIA: Document Interchange Architecture Services 


Figure 2-24. Overview of LU 6.2 Components 
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Transaction Program 
r---ccc ccc —> 


PS Verb Router 


PS INITIALIZE 


any verb issued 


A 
other 
PS for PS for PS for PS 
Mapped Sync Point Control verb 
Conversations| Services Operator handlers |Conversations 
PS.MC PS.SPS PS.COPR oe 8 PS .CONV 
a 
V V 


Resources Manager 


Half—Session or 
Resources Manager 


*\ LEGEND: 
wa ---> Call/Return relationship (within a process) 
< > Send/Receive relationship (between processes ) 
Note: PS verb router is called recursively by PS verb handlers. 
Figure 2-25. Structure of a Presentation Services Process 


sage units between the format useful to 
conversing programs and the format appropri- 
ate for the path control network (this 
includes implementing session services such 
as pacing and cryptography). 


C) 


This group of components is managed by the 
session manager component (SM), which creates 
and destroys half-sessions and interacts with 
components outside the LU (e.g., the control 
point). 


FUNCTIONAL SUMMARY BY FUNCTION 


This is the first of two sections describing 
the functions and interactions of LU compo- 


nents. This section is organized by func- 
tion; 1it concentrates on functions that 
involve multiple components. For each func- 
tion, it explains in approximate time 


sequence the roles of the various LU compo- 


nents. The next section is organized by com- 
ponent, and covers’ functions’ performed 
principally by one component. A full 


description of each component is given in its 
corresponding chapter of this book. 


For illustrations of the component inter- 
actions discussed in this section, including 
a variety of cases not discussed elsewhere in 
this chapter, see "Component Interactions and 
Sequence Flows" on page 2-48. In particular, 
Figure 2-33 on page 2-50 and Figure 2-34 on 
page 2-51 illustrate the interactions, at the 


i source and target LUs, respectively, for a 
2 typical conversation; Figure 2-35 on page 
a 2-52 and Figure 2-36 on page 2-53 illustrate 


typical interactions for session deacti-. 


vation. 


The session manager component is created by 
the node operator facility (NOF) when it 
activates the LU. The session manager compo- 
nent then creates the resources manager com- 
ponent. They run continuously thereafter. 
(For more information see SNA Type 2.1 Node 
Reference and "Chapter 4. LU Session Manag- 
er". ) 


The LU manages the state and configuration of 
its local resources, including transaction 
programs » conversation resources » and 
half-sessions. It cooperates with other LUs, 
using shared sessions and conversations, to 
configure these resources to support distrib- 
uted transactions. (An LU implementation 
might also manage other, non-SNA, resources 
such as processor execution cycles, storage, 
and data bases. ) 


The principal functions leading to LU trans- 
action processing are the following, not nec- 
essarily performed in this order: 


e Activating sessions between two LUs 


Invoking transaction programs 


Initiating conversations between the 


transaction programs 


Transferring message units between the 
transaction programs 
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2-30 
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EXAMPLE TRANSACTION PROGRAM 


Figure 2-26 on page 2-30 outlines some typi- 
cal verb issuances for an example pair of 
transaction programs. 


SOURCE TP TARGET TP 
MC_ALLOCATE 


MC_SEND_DATA MC_RECEIVE_AND_WAIT 


MC_RECEIVE_AND_WAIT " 
MC_SEND_DATA 


ig MC_DEALLOCATE 
MC_DEALLOCATE 


Example of Communicating 
Transaction Programs 


Figure 2-26. 


The programs, running at different LUs, issue 
complementary sequences of verbs. The LUs 
convert these executed verbs into 
message-unit flows. 


MESSAGE-UNIT TRANSFER 


First, consider transfer of message units. 
Assume that two transaction programs are run- 
ning at their respective LUs and are con- 
nected by a mapped conversation. For the 
programs to transfer data, one program must 
issue MC_SEND_DATA verbs while the other 


issues complementary MC_RECEIVE_AND_WAIT 
verbs. 

The TP invokes PS for each 
' transaction-program verb it issues. PS per- 


‘forms the function appropriate to the specif- 


ic verb. For each verb, PS verifies that the 
verb is valid in the current conversation 
state, converts the verb parameters to an 
intermediate representation, and _ performs 
verb-specific processing that includes issu- 
ing appropriate requests to other LU compo- 
nents. : 


When sending, the data specified on the 
MC_SEND_DATA verb along with the chaining 
indicators is put into MUs by PS and sent to 
HS. HS encodes the protocol information into 
RHs and passes the resulting BIUs (with TH 
information) to path control. 


When receiving, HS checks incoming BIUs for 
format and protocol validity and passes MUs 
containing data to PS. When the TP issues a 
MC_RECEIVE_AND_WAIT verb, PS checks the verb 
for validity and passes the requested amount 
of data and protocol information back to the 
TP. 


The following sections discuss these func- 
tions in more detail. (Figure 2-4 on page 
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- cessive 


2-16, Figure 2-5 on page 2-17, and Figure 2-6 
on page 2-18 illustrate the message-unit 
relationships discussed. ) 


Sending Data 


For MC_SEND_DATA, PS verifies that the con- 
versation is in send state. If mapping is 


being performed; PS | maps. the 
transaction-program data record into a 
mapped-conversation record (see "Mapping 


Function" on page 2-36). It transforms the 
MCR into a sequence of logical records of 
implementation-defined length by segmenting 
the supplied data and prefixing the appropri- 
ate GDS LLID fields. It calls the basic con- 
versation SEND_DATA procedure as often as 
necessary (determined by the buffer-record 
size used by the PS.MC implementation) to 
send all the logical records. The 
mapped-conversation verb handlers in PS typi- 
cally call one or more basic-conversation 
procedures to perform the function requested 
by a mapped-conversation verb. 


When PS has first entered send state, it 
expects an LL at the beginning of the first 
buffer record. From then on, PS compares the 
accumulated length of the data passed on suc- 
issuances of MC_SEND_DATA to the 
logical-record lengths specified in the LLs;,> 
thus verifying that the conversation message 
sent ends at a logical record boundary. 


PS accumulates the data from successive buff- 
er records in RU-sized units (the RU size for 
a session is determined by BIND negotiation 
when the session is activated). When the 
RU-size buffer is full, PS transfers the data 
to HS with an indication of whether it is the 
last of the data for a conversation message. 
When PS detects the end of a _ conversation 
message >» e.g.» a PREPARE_TO_RECEIVE, 
MC_RECEIVE_AND_WAIT,; CONFIRM, SYNCPT , or 
MC_DEALLOCATE verb was issued, PS transfers 
its remaining accumulated data with an indi- 
cation of how the conversation message was 
ended, e.g.» confirmation request, conversa- 
tion turnaround, or deallocation. It also 


places the conversation in the appropriate 
state. 

Meanwhile, the HS process, also in send 
state, waits for data from PS. When PS 
passes the data, HS fills in the RH, a 


sequence number, and other TH information. 
If session cryptography is being used, HS 
enciphers the data. 


HS encodes each RH to indicate the beginning 
or end of a bracket (corresponding to a com- 
plete conversation exchange) and the begin- 
ning or end of a chain (corresponding to a 
conversation message). For all but the last 
BIU in a chain, HS encodes the RH with RQ@E1. 


For the last BIU for the conversation mes- 
sage, HS encodes the RH with EC (the 
end-of-conversation-message indicator) and 
other indicators selected by PS, such as CD 
(e.g.» MC_PREPARE_TO_RECEIVE verb issued), 
RQD2. (e.g.,  MC_CONFIRM issued), RQD1 


au 


\ 


C- 


* 


“—— 


(MC_DEALLOCATE TYPELABEND]) issued), and CEB 
(MC_DEALLOCATE issued). HS changes the local 
session state accordingly. 


HS passes each completed BIU and the corre- 
sponding TH information to path control for 
transmission to the receiving HS in_ the 
remote LU. 


HS enforces both fixed and_= adaptive 
session-level pacing. The type of pacing for 
a given session is determined during session 
initiation and is communicated to HS when 
initialized by SM. 


In fixed pacing, the sending HS sends at most 
one fixed-sized pacing window of BIUs before 
receiving a pacing response. It then 
requires a pacing response from the receiver 
before sending another window. The receiving 
HS sends a pacing response when it can 
receive another pacing window, e.g.» when it 
has enough free buffers. 


In adaptive pacing, the pacing window size 


varies depending upon the availability of 


buffers at the receiving node and the demand 
for buffers at the sending node. The avail- 
ability of buffers is determined and con- 
trolled by the buffer manager (BM) at the 
receiving node. 


The sending HS asks the receiving HS for the 
next-window size by setting the Pacing indi- 
cator to 1 (PAC) in the RH of the first mes- 
sage in a window. Also in the same RH, the 
sending HS may ask for a larger window size 
by setting the Request Larger Window indica- 
tor to 1 (RLW). 


The receiving HS calculates the next-window 
size based upon the number of buffers given 
to it by the buffer manager and the demand 
for buffers by the sending HS. The receiving 
HS sends the next-window size to the sending 
HS in a pacing message (IPM), which corre- 
sponds to the pacing response (IPR) in fixed 
pacing. When additional buffers are avail- 
able and the Request Larger Window indicator 
is RLW, the window size is increased. When 
additional buffers are not available, the 


window size remains the same. When fewer 
buffers are available, the window size is 
decreased. When buffers become critically 


scarce, the buffer manager prompts’ the 
receiving HS to send an unsolicited pacing 
message to the sending HS, which causes the 
sending HS to set its current-window size and 
next-window size to 0, thus stopping the 
sending HS from sending BIUs. When buffers 
again become available, the buffer manager 
prompts the receiving HS to send another pac- 
ing message with a next-window size greater 
than O to the sending HS. This allows the 
sending HS to resume sending BIUs. For more 
information on session-level pacing’ see 
"Chapter 6.2. Transmission Control". 


Receiving Data 


The HS process at the receiving LU receives 
BIUs and TH information from path control. 


It sends IPRs or IPMs when it has sufficient 
buffers to receive additional BIUs. If ses- 
sion cryptography is specified, it deciphers 
the data. It checks for correct session pro- 
tocol. It checks BIU sequence numbers to 
detect lost or duplicate BIUs and to corre- 
late responses with the correct bracket. If 
it detects any protocol error, it abnormally 
deactivates the session, 1.e., it requests SM 
to issue UNBIND indicating a format or proto- 
col error. 


If the BIU is satisfactory, HS sends the MUs 
containing the Security FM header or the 
Attach FM header, if present, to RM, and 
sends all other MUs to PS. HS also sends PS 
an indication of significant state changes 
that were encoded in the received RH such as 
end of a. conversation message (End-of-Chain), 
enter send state (Change-Direction), confir- 
mation request (Definite-Response 2/3) and 
end of conversation 
(Conditional-End-of-Bracket). HS changes its 
own session state accordingly. 


Meanwhile, the receiving TP issues 
MC_RECEIVE_AND_WAIT verbs to receive the con- 
versation message. Each verb issuance calls 


PS. 


For each MC_RECEIVE_AND_WAIT issuance, PS 
calls the basic conversation RECEIVE_AND_WAIT 
procedure until it receives enough data (in 
the form of logical records) to satisfy the 
data length requested on the 
MC_RECEIVE_AND_WAIT verb. 


For each RECEIVE_AND_WAIT verb issuance (in- 
cluding the case in which RECEIVE_AND_WAIT is 
issued directly by a transaction program, 
1.e., for a basic conversation), PS waits for 
the data from HS. PS receives data from HS 
in the form of MUs. If more MUs are received 
than are currently necessary to satisfy a 
RECEIVE_AND_WAIT, PS queues the MUs. 


While parsing the MUs’~ to satisfy the 
RECEIVE_AND_WAIT, PS keeps track of the LL 
fields, to verify that the conversation mes- 
sage ends on a logical record boundary. 


When the RECEIVE_AND_WAIT procedure returns 
to the MC_RECEIVE_AND_WAIT procedure, PS 
checks the length and continuation fields in 
the LLs to verify that a complete 
mapped-conversation record (MCR) has’ been 
received, strips the GDS LL and ID fields, 
and reblocks the data into an MCR. (If the 
TP receive buffer cannot contain the complete 
MCR > PS passes it to the TP in 
receive-buf fer-sized segments » 1.@.5 
mapped-conversation buffer records. ) 


If PS receives an end-of-conversation-message 
indication, it does not forward this indi- 
cation to the TP until after all logical 
records and MCRs have been received. It then 
returns the end-of-conversation-message indi- 
cation alone on the next MC_RECEIVE_AND_WAIT 
verb issued, and places the mapped conversa- 
tion into the appropriate state. 
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TRANSACTION PROGRAM INITIATION AND TERMI- 
NATION 


Before the TPs can exchange message units, 
the TPs must be brought into execution. 


a ee ed 


Assume that a source TP is already in exe- 
cution. It requests invocation of a remote 
TP by issuing the ALLOCATE verb (or 
MC_ALLOCATE, which PS.MC converts into an 
ALLOCATE). It identifies the program to be 
invoked by specifying the remote transaction 
program name and remote LU name, and selects 
the desired transport characteristics by 
specifying a mode name. 


Using the parameters from ALLOCATE, the 
source PS builds an Attach FM header and 
sends it to HS for transmission to the part- 
ner LU. When the target HS receives the 
Attach FM header, it passes it to its RM. 
This RM checks some parameters in the Attach 
FM header, including any security parameters 
in the Attach. If a format or protocol error 
is found, the Attach FM header is rejected by 
terminating the session that it arrived on. 
If no format or protocol error is found but 
the Attach contained invalid or inadequate 
information, RM sets a sense data field, cre- 
ates a PS process and passes it the Attach FM 
header with the sense data. Upon finding the 
sense data, the new PS builds and sends an FM 
Header 7 containing the sense data, thus 
rejecting the Attach. If RM finds no errors, 
1t creates a PS process and passes it the 
Attach FM header with no sense data. The new 
PS analyzes the Attach FM header further and, 
if an error is detected, rejects it; other- 
wise, PS selects and loads the specified 
transaction program code, and calls it, plac- 
ing it initially in receive state for the 
conversation. 


Once a target TP is invoked, it can act in 
turn as a source TP to invoke other TPs. If 
conversation-level security is required by 
the other TPs, the same security user ID that 
initiated the original target TP may be used, 
along with an Already Verified indicator in 
the Attach FM header, or the source TP may 
supply the required security parameters. 


Initiating the Initial Local Transaction Pro- 
gram 


The first TP activated for a distributed 
transaction is initiated by a START_TP record 
received by RM from an initiator process on 
the same system. Examples of an initiator 
process are an application, the node operator 
facility (NOF ), a TP-PS process, a 
control-point process, or RM itself. The 
START_TP record contains information such as 
the name of the TP to be started; security 
tokens of the requester, e.g., user ID, pass- 
word, profile; an indication as to whether a 


Peer Protocols 


reply to the START_TP request is desired, and 
the initiating process's name and ID. 


RM treats the START_TP much like an Attach: 
the requested TP-PS process is created and 
initialized; however, no _ conversation § is 
associated with a START_TP request. 


Terminating a Transaction Program 


A TP ends by returning to PS.INITIALIZE. PS 
then performs any necessary final processing 
(such as deallocating the TP's remaining con- 
versations), and notifies RM. If no queued 
START_TP or Attach requests exist for the TP, 
RM destroys the PS process. 


CONVERSATION ALLOCATION AND DEALLOCATION 


A source TP initiates a conversation with a 
target TP by issuing the ALLOCATE (or 
MC_ALLOCATE) verb. 


The source PS satisfies the TP request in two 
steps. 


First, PS sends RM a request to allocate a 
conversation. RM creates a conversation 
resource and notifies PS. 


Second, PS sends RM a request to assign a 
session to the conversation. When RM has a 


session available for the conversation, RM 


connects the PS process of the issuing TP to 
the HS process of the session and notifies PS 
and HS. PS places the source end of the con- 
versation (where the allocation was 
requested) initially in send state. 


If a session is not immediately available, RM 
suspends the issuing process. 


After a session is assigned to the conversa- 
tion at the source LU, PS sends the Attach FM 
header to HS for transmission to the target 
LU. 


When HS at the target LU receives the first 
BIU of the bracket, it notifies RM. RM 
receives the Attach from HS, creates the con- 
versation resource, and makes it accessible 
to HS and PS. It places the target end of 
the conversation initially in receive state. 


The following sections give further details 
of these functions. 


Selecting a Session 


RM maintains a list of allocation requests 
and a list of free sessions and their con- 
tention polarities. If RM has an allocation 
request (1i.e., from an ALLO- 
CATE(CRETURN_CONTROL = 
WHEN_SESSIGN_ALLOCATED)} and a first-speaker 
(contention-winner) session is free (1.e.) in 
between-brackets state), RM allocates that 
session to the conversation. If a 
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first-speaker session is not free but a bid- 
der (contention-loser) session 1s free, RM 
bids for the session. If no sessions are 
free, but the session limits have not been 
reached, RM requests that SM activate a new 
session. If no sessions are free and the 
session limits are reached, RM queues the 
allocation request to await the freeing of a 
session. : 


Bidding 


RM requests HS to attempt to begin a bracket 
by sending an RU with BB; this is called 
bidding for the session. 


RM always accepts a bid received on a bidder 
session. 


If RM receives a bid on a first-speaker ses- 
sion, RM accepts or rejects the bid depending 
on whether any of its own transactions need 
to allocate the session for use by their own 
conversation (if they do, then it sends a 
negative response to the bid; otherwise, it 
sends a positive response to the bid). 


Optionally, a negatively-responding RM will 
inform the partner when it is again willing 
to accept a bid. 


Newly Active Session 


When a session becomes newly active, it is 
initially in in-brackets state. If LU-LU 
verification is active, RM at the primary LU 
creates and sends (via HS) a Security FM 
header (FMH-12) to the secondary LU's RM for 
verification. The LU that activated the ses- 
sion (the primary LU, or BIND sender) has 
first right to send, regardless of the ses- 
sion contention polarity. If RM at the pri- 
mary LU has no_ unsatisfied conversation 
request when a.session becomes active, it 
requests HS to yield the session, i.e., to 
end the bracket. 


Deallocation 


When PS requests deallocation of the conver- 
sation, HS ends the current bracket, and RM 
deletes the conversation resource and places 
the session in the free-session list. 


SESSION ACTIVATION AND DEACTIVATION 


If RM has a conversation request for a ses- 
sion but no session is free and the session 
limits have not been exceeded, RM requests SM 
to activate a new session. RM also requests 
session activation as a result of operator 
commands (such as INITIALIZE_SESSION_LIMIT). 


Starting a Session 


Starting a session involves the following 
three activity phases: session limits 
initialization, session initiation, and ses- 
sion activation. 


Initializing Session Limits: Prior to any 
transaction activity, the control operator 
sets limits on the maximum and minimum num- 
ber, and contention polarity, of active ses- 
sions with particular partner LUs using 
particular mode names (see "Control-Operator 
Functions" on page 2-36 for details). 


Session Initiation: When SM receives a ses- 
sion activation request from RM, SM sends an 
ASSIGN_PCID record to the session services 
(SS) component of the CP. SS responds by 
sending to SM an ASSIGN_PCID_RSP record con- 
taining the fully-qualified procedure 
correlator ID that uniquely identifies the 
potential session and the procedures related 
to that session. 


SM then sends an INIT_SIGNAL record to SS; 
which directs the control point to mediate 
the initiation of the session. SS sends to 
SM a CINIT_SIGNAL record containing session 
characteristics and information to be 
included in the BIND. 


SM then sends an ASSIGN_LFSID record to the 
address space manager (ASM) component of the 
CP. ASM responds with an ASSIGN_LFSID_RSP> 
which contains the local-form session identi- 
fier (LFSID) for the potential session. 
Refer to "Chapter 4. LU Session Manager" for 
more details of session initiation. 


Session Activation SM then generates a BIND 
RU containing the desired session parameters. 
If security is used, the session parameters 
include randomly generated data for LU-LU 
verification and an indication of the amount 
of conversation-level security support that 
is defined for the secondary LU. Random and 
enciphered data are sent/received only when 
LU-LU verification is active. SM sends the 
BIND to its local CP for routing to the part- 
ner LU. 


SM for the LU receiving the BIND (the second- 
ary LU or SLU) negotiates the proposed ses- 
sion parameters to acceptable values; 
enciphers the received random data based upon 
the LU-LU password; saves the indication of 
the primary LU's conversation-level security 
support for the secondary LU; and creates a 
positive response to BIND. The _ positive 
response to BIND includes an indication of 
the secondary LU's conversation-level securi- 
ty support for the primary LU, randomly gen- 
erated data, and the enciphered version of 
the random data received in BIND. SM sends 
this positive response to BIND via its local 
CP. 


When the positive response to BIND is sent or 
received, the session manager at each end 
connects a new HS process to the path control 
network. If the session uses cryptography, 
the HSs exchange cryptography-veri fication 
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RUs. Then, each SM notifies its RM that a 
new session is available. If LU-LU verifica- 
tion is active, before the new session is 
available for conversations, the primary LU's 
RM enciphers the random data received on the 
response to BIND and returns it to the sec- 
ondary LU's RM for verification. 


If the LUs cannot agree on session parame- 
ters, or the enciphered random data compar- 
ison fails, the session activation fails. 


Session Outage 


If session outage occurs, SM notifies RM. If 
a conversation was active on the session, RM 
notifies PS, which notifies the transaction 
program of conversation failure. RM requests 
SM to activate another session if it has 
unsatisfied conversation requests oor = an 
unsatisfied auto-activation limit. 


Ending a Session 


Ending a session involves the following three 
activity phases: operator request, session 
shutdown, and session deactivation. 


Operator Request: Sessions are not deacti- 
vated in the normal course of transaction 
program processing; they are deactivated 
normally only upon specific request from the 
control-operator transaction program. (Ses- 
sions are deactivated abnormally because of 
protocol violations and physical connectivity 
problems. } 


When the LU operator ‘at either end of a ses- 
sion determines that a session is to be deac- 
tivated, the control-operator transaction 
program issues a control-operator verb. The 
control operator can cause sessions to end in 
two ways. 


The operator can issue a RESET_SESSION_LIMIT 
verb to reset the session limits to 0 for 
specified partner LUs and mode names. The LU 
proceeds with subsequent phases until there 
are no active sessions for the specified 
(LU,mode) pairs. 


FUNCTIONAL SUMMARY BY COMPONENT 
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This section is organized by component; it 
reviews the specific functions of each prin- 
cipal component, and describes functions per- 
formed primarily in one component. 


Presentation Services 
PS manages transaction programs and controls 


conversation-level communication between TPs: 


Peer Protocols 


The operator can also issue a DEACTI- 
VATE_SESSION verb to deactivate a specific 
session (this might be done, for example, to 
recover from certain error situations). This 
does not change the session limits, however, 
so the LU might activate another session to 
replace it. 


When PS.COPR receives the verb, it issues a 
session-limit-change notification or a 
session-deactivation request to RM. 


Session Shutdown: When RM receives a 
session-limit-change notification, RM first 
performs drain processing. If the operator 
has requested RESET_SESSION_LIMIT with drain 
indicated, then RM performs no deactivations 
until all requests for allocation of sessions 
with the specified mode name have been satis- 
fied. 


When drain is complete, or when RM receives a 


session-deactivation request, and an affected ( 


session next enters between-brackets state, 
RM initiates a bracket-termination protocol. 
This consists of an exchange of 
bracket-initiation-stopped (BIS) RUs assuring 
that all brackets have completed at both ends 
of the session, i1.e., that no other BIUs are 
in transit between the LUs. 


the partner LU drains 
sends BIS in 


After receiving BIS, 
its allocation requests and 
return. 


ee 


GO 
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When the BIS protocol is complete, the RM/ 
that initiated the BIS protocol instructs its\ 


SM to deactivate the session. 


Session Deactivation: When SM receives a 
session-deactivation request from RM, it 
sends UNBIND, via the local CP, and awaits a 
response. When the partner SM receives an 
UNBIND, it unconditionally sends a positive 
response. When the response to UNBIND is 
sent or received, the corresponding SM dis- 
connects the half-session process from the 
path control network, notifies the CP that 
the session is ended, and destroys’ the 
half-session process. 


e Loads and calls the transaction program 
e¢ Maintains the conversation protocol 
state, e.g.» send/receive state of the TP 


e Enforces correct verb parameter usage and 
sequencing constraints ° 


e Coordinates specific processing for each 
verb 


eo 


¢ Performs mapping of transaction ae 


data into mapped-conversation records 


e Converts mapped-conversation records to 
GDS variables, and the reverse: it par- 
titions the data into logical records and 
generates LLID prefixes 


e Blocks data into RU-sized message units 
(MUs ) 


e Reblocks MU data from HS into logical 
records or buffer records as required by 
the TP 


® Verifies logical-record length and bound- 
aries 


e Truncates or purges data when errors are 
reported or detected by the TP 


e Generates and issues FM headers’ for 
Attaches and Error-descriptions 


Half-Session 


HS controls session-level communication 


between LUs: 


e Builds RHs and enforces correct RH param- 
eter settings 


e Creates chains and enforces chaining as 
the unit of LU-to-LU error recovery 


e Correlates responses with the correct 
bracket ' 


® Enforces bracket protocol and _ purges 
rejected brackets 


e Enforces protocols for the relevant FM 
and TS profiles for the session (FM pro- 
file 19 and TS profile 7) 


e¢ Generates and enforces sequence numbering 
to detect lost or duplicate BIUs 

e Provides session-level pacing (none, 

fixed, or adaptive) 


° Exchanges cryptography-verification RUs 
when session cryptography is being used 


e Enciphers and deciphers data when session 
cryptography is being used 


Resources Manager 


RM manages presentation services and conver- 
sations 


e Creates and destroys instances of presen- 
tation services 


e Creates and destroys conversation 

| resources and connects them to 
half-sessions and to presentation serv- 
ices 

® Finishes LU-LU verification for 


session-level security by generating and 
processing Security FM headers (FMH-12s) 


e Performs all conversation-level security 
checks, verifies conversation-level pass- 
words, and controls access to protected 
transaction programs 


¢ Maintains the data structures represent- 
ing the dynamic relationships among con- 
versation resources > half-sessions » 
transaction program instances, and trans- 
action program code 


e Chooses the session to be used by a con- 
versation and controls contention for the 
session 


e Performs drain action: allows’ session 
traffic to cease before requesting ses- 
sion deactivation 


e Requests SM to activate and deactivate 
sessions 


Session Manager 


SM manages sessions: 


© Coordinates session initiation in concert 
with the control point 


e Sends and receives BIND 


e Supplies and negotiates session parame- 
ters during BIND exchange 


e Exchanges cryptographic Key and session 
seed 


e Exchanges random and enciphered data and 
performs initial LU-LU verification 


e Notifies RM of session outage 


e Creates and destroys hal f-session 
instances and connects them to path con- 
trol instances 


FUNCTIONS OF COMPONENTS OF THE NODE EXTERNAL 
TO THE LU 


Buffer Manager: The primary objective of the 
node buffer manager is to manage buffer 
pools. The LU uses these facilities for 
session-level pacing. The facilities pro- 
vided by the node buffer manager are: 


e A mechanism to increase and decrease 
buffer resources used by a process based 
on fair sharing of limited storage 

e 6A mechanism that notifies buffer users 
when buffer resources are in critically 
short supply 

e A mechanism that allows processes to wait 
for buffer resources to become available 


Type 2.1 Node Control Point (T2.1 CP): The 
T2.1 node control point allows peer-to-peer 
connection of distributed processors’ by 
assisting in the activation of links and ses- 
sions, e.g.» it locates partner LUs, sets the 
path, assigns LFSIDs. For more information 
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tions to 


on T2.1 node control points refer to SNA Type 
2.1 Node Reference. 

Node Operator Facility (NOF): NOF manages the 
activation and deactivation of the LU. 


Initiator Process: An initiator process is 
any process in LU's local system that has 
addressability to the RM component of the LU. 
The initiator process is considered privi- 
leged in that it may use this addressability 
to send records to the LU that cause the LU 
to perform specific functions, e.g., to cre- 
ate a transaction program that initiates a 
distributed transaction. 


FUNCTIONS OF SERVICE TRANSACTION PROGRAMS 


Service transaction programs provide func- 
e end user that require communi- 
cation with another LU using a= special 
SNA-defined pattern of verbs. 


Service TPs form part of a distributed trans- 
action similarly to other TPs. They have a 
transaction program name and are invoked by 
the Attach mechanism, and they exchange 
information with these other TPs by issuing 
transaction-program verbs. 


Service transaction programs differ from 
user-application transaction programs in that 
they are SNA-defined and are considered part 
of the LU. The names of service transaction 
programs are SNA-defined. The records that 
service TPs send and receive are SNA-defined 
GDS variables. 


Control-Operator Functions 


All LUs have an implementation- or 
installation-defined control operator trans- 


action pregran (COPR TP) that represents the 


LU control operator's interface to the LU. 
Using a program-selected means such as opera- 
tor console input, this TP issues 
control-operator verbs to perform 
control-operator functions. 


Control-operator verb functions include cre- 
ation and modification of the data structures 
that describe the LU and the LU-accessed net- 
work resources: control points, transaction 
programs, partner LUs, and modes. Other 
control-operator verb functions limit the 
numbers and contention polarities of sessions 
with particular LUs for particular mode 
names, and also determine when sessions will 
be activated and deactivated. | 


For an LU that supports parallel sessions, 
there are additional transaction services 
components for the control operator. These 
LUs contain a change-number-of-sessions 
(CNOS) service transaction program. When 
processing CNOS verbs, the COPR TP at one LU 
exchanges GDS variables with the CNOS service 
TP at its partner to reach mutual agreement 
about limits on the number of parallel ses- 
sions between them. 
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(Control-operator functions are discussed in 


further detail in "Chapter 5.4. Presentation ~~~ 


Services--Control-Operator Verbs" . ) 
SNA Distribution Services 


SNA Distribution Services (SNA/DS) provides a 
set of verbs that an application TP may issue 
to request asynchronous distribution of data. 


The service is provided by a network of dis- 
tribution service units (DSUs) interconnected 
by conversations and sessions. Each DSU con- 
sists of PS verb handlers and a collection of 
service TPs within the LU. The service TPs 
provide data storage, routing, and distrib- 
ution asynchronously with the origin or des- 
tination application programs. 


SNA/DS is described in the publication SNA 
Format and Protocol Reference Manual: Dis- 


ey 


tribution Services. ; eee 
Document Interchange Services 
Document . Interchange Architecture (DIA) 
describes formats and protocols for synchro- 
nous exchange of documents by using 
basic-conversation verbs in a prescribed way. 
Document interchange services include service 
TPs for synchronous document transfer. 

yes 


| 


Document interchange architecture is| 


described in the publication Document Inter- ~~ 


change Architecture--Concepts and Structures. 
OPTIONAL FUNCTIONS 


This section describes the principal optional 
function sets. 


Mapping Function 


The mapping function is an optional function 
of mapped conversations (PS.MC) that allows a 
TP to select transformations, called maps, to 
be applied to TP data at the sending and 
receiving TP protocol boundaries. Maps are 
non-SNA-defined transformation tables or pro- 
cedures that can be defined by the installa- 
tion at both the source and target LUs. Maps 
can specify, for example, how fields of a 
mapped-conversation record are related to the 
TP variables (data record) referred to in 
protocol-boundary verbs. 


Each LU can support multiple maps. Each map 
is identified by a map name. The maps to be 
applied are selected by the transaction pro- 
gram (via verb parameters) and by other maps 
(in an implementation-defined way), as shown 
in Figure 2-27 on page 2-37. 


Three separate map-name name spaces siete 


(terms in parentheses correspond to those in 
the figure): 


C) 


Figure 2-27. Map Name Usage by Mapped Conversations 


1. Sender locally-Known map name: This map 
name (map-name-1)} 1s Known to the TPs at 
the sending LU. It identifies a map 
(map-1) at the sending LU that defines 
the transformation performed by the send- 
er from the format of the sending-program 
data (data-1) to the format of the MCR 
(data-2) that is sent on the conversa- 
tion. This map also defines a _ corre- 
spondence between the sender 
locally-known map name (map-name-1) and 
the globally-kKnown map name (map-name-2 ) 
described below. 


2. Globally-Known map name: This map name 
(map-name-2) 1s Known at both the sending 
and receiving LUs, and is transferred on 
the conversation between sender and 
receiver. It identifies a map (map-2) at 
the receiving LU. This map defines the 
transformation performed by the receiver 
from the format of the MCR received on 
the conversation (data-2) to the format 
of the data presented to the receiving 
transaction program (data-3). This map 
also defines a correspondence between the 
globally-known map name (map-name-2) and 
the receiver locally-Known map name 
(map-name-3) described below. 


3. Receiver locally-Known map name: This 
map name (map-name-3) is Known to TPs at 
the receiving LU. This identifies the 
format of the data presented to the pro- 
gram (data-3), e.g.» it allows the pro- 
gram to select the correct structure 
definition or format description for the 
data produced by the execution of the 
receiver map (map-2). 


Mapping is performed by a PS.MC component 
called the mapper. 


The mapper at the sender selects the send map 
specified by the sender locally-known map 
name, which is supplied as a parameter of the 
MC_SEND_DATA verb. It performs the send map- 
ping on the TP-supplied data, producing a 
mapped-conversation record. Using the sender 
map >» the mapper. also selects the 
globally-kKnown map name. 
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% * % * 
[x x | jx] 
| | Sender map (map-1) I | Receiver map (map-2) 
x x 
I | 
| | 
V V 
oS erie | 
source TP sends: | ; transferred on conversation: | | target TP receives: 
| : I l 
map-name-1, data-1 | |  map-name-2, data-2 | | map-name-3, data-3 
———_________—> | | >| | > 
| | I l 
| Send I | Receive | 
| Mapping | | Mapping | 
| Cee rie eee rer 


The LU sends the globally-Known map name over 
the conversation in an SNA-defined map-name 
GDS variable (see SNA Formats), and sends the 
mapped-conversation record in a separate GDS 
variable. 


The mapper at the receiver selects’ the 
receive map specified by the globally-kKnown 
map name received. It performs the receive 
mapping on the mapped-conversation record it 
receives, resulting in data formatted for 
presentation to the TP. Using the receiver 
map» the mapper also selects the receiver 
locally-kKnown map name. PS.MC passes the 
receiver locally-Known map name and_ (the 
reformatted data to the TP as returned param- 
eter values for the next receive verb issued, 
e.g.» MC_RECEIVE_AND_WAIT. 


The receiving TP uses the receiver 
locally-Known map name in a TP-determined way 
to interpret the received data. 


The TPs supply or receive a map name parame- 
ter value for each send or receive verb 
issued, respectively. The LU, however, does 
not send another map-name GDS variable if the 
globally-kKnown map name has not changed from 
that of the previous record sent. To accom- 
plish this, the mapper at each LU retains the 
most recently sent and most recently received 
values of map-name-2 for the conversation 
(the send and receive map names can be dif- 
ferent). The retained values for each direc- 
tion persist until changed or until the end 
of the conversation, regardless of interven- 
ing turnarounds. 


Sync Point Function 


The sync point function allows all TPs proc- 
essing a distributed transaction to coordi- 
nate error recovery and maintain consistency 
among distributed resources such as_ data 
bases. 


The sync point functions affect protected 


resources. These include conversation 
resources and imp lementation- or 
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installation-designated resources such as 
data bases. Any changes to ae protected 
resource are logged so that they can be 
either backed out (reversed) if the trans- 
action detects an error, or committed (made 
permanent) if the transaction is successful. 


The transaction programs divide the distrib- 
uted transaction into discrete, synchronized 
logical units of work (LUNs), delimited by 
synchronization points (sync points). (Cor- 
responding sync points occur at each TP par- 
ticipating in the distributed transaction. ) 
LUNs are sequences of operations that are 
indivisible units for the application, i.e., 
any failure in an LUW invalidates the entire 
LUW (all LUW processing by all TPs for the 
transaction), 
out to the previous sync point. 


The LU components for the sync point function 
are shown in Figure 2-28 on page 2-39. 


Highlights of the sync point function are 
discussed below. (See "Chapter 5.3. Presen- 
tation Services--Sync Point Services Verbs" 
for details. ) 


Sync Point Control: The sync point function 
at each LU is coordinated by PS.SPS. 


For each TP process participating in the dis- 
tributed logical unit of work, the corre- 
sponding PS.SPS tracks the state of that 
logical unit of work. To do this, PS.SPS has 
protocol boundaries with the TP and with the 
protection managers for each conversation and 
for each protected local resource allocated 
to: that TP. 


Logging: When processing a given logical 
unit of work, whenever a TP issues a verb 
that makes any changes to ae protected 
resource, the corresponding resource pro- 
tection manager logs the change so that, if 
necessary, the change can be backed out lat- 
er. 


The log manager maintains the log entries for 
each active LUW (1i.e., for each active trans- 
action) on non-volatile storage, using 
implementation-defined data-management func- 
tions. The same log is used to record all 
log entries for all the LU resources for the 
LUW. 


Resources Manager: When it creates the PS 
process, RM provides PS.SPS with access to 
the log. 


In some cases, a transaction program can ter- 
minate normally before its syne point log 
entries are erased. In these cases, RM 
assumes the function of the terminated sync 
point control to complete the protocol and to 
release (forget) the log entries. 


Protection Managers: Each protected 
resource, e.g.» a conversation or a local 
data base, has a protection manager that logs 
Significant state nges during a_ logical 
unit of work, detects errors affecting the 
integrity of the changes, and commits or 
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so the transaction is backed. 


backs out the changes as determined by the 
sync point protocol. 


The protection manager for a conversation is 
defined by SNA; protection managers for other 
(non-SNA) resources are defined by the imple- 
mentation, but have a similar protocol bound- 
ary to PS.SPS. The protection managers form 
a sublayer between PS verb handlers and the 
resource-control components. 


Sync Point Protocol: At the end of a logical 
unit of work, an application-designated TP 
initiates sync point. The LUs then carry out 
a protocol involving all local protected 
resources and conversations being used by the 
TP, and all partner LUs and TPs directly con- 
nected by those conversations, to determine 
whether any TP or protected resource detected 
an error in the LUW, and to propagate this 
result to the other LUs and TPs. 


C 


When a TP issues a verb that invokes the a ae 


point function (e.g., SYNCPT, BACKOUT) its 
PS.SPS coordinates the sync point protocol. 
PS.SPS exchanges sync point commands, in the 
form of presentation services (PS) headers 
and FM headers, over the TP's conversations 
with other TPs. Each PS.SPS component for 
the transaction performs similar exchanges, 
in turn, with its TP's conversation partners. 
The PS.SPS components also determine the sta- 
tus of local non-SNA resources by exchanging 
appropriate commands across their internal 
protocol boundaries. 


the protection managers to complete any pend- 


ing log entries for the LUW. s 


The sync point protocol culminates with a 
mutual decision among all TPs processing the 
LUN either to commit or to back out the LUW. 


Commitment and Back-Out: When the sync point 
protocol is complete at a particular TP, the 
resource control components use the LUW log 
entries to supply the information needed 
(e.g.» data base change records) to perform 
the required commitment or back out. They 


Ne 


These exchanges direct -— 


é 
ay ae 


RY 


then notify PS.SPS to erase the log entries\ 


for that LUW. 


Resynchronization: An LU failure might occur 


during the sync point protocol, so that some 


LU never receives an expected LUW status 
report. To recover from this case, the other 
LUs can wait until the failing LU is reini- 
tialized, and then the LUs perform a resyn- 
chronization (resync) protocol to complete 
the sync point processing at each LU. Resync 
uses service transaction programs to exchange 
sync point status among the LUs. 


When the failing LU is reactivated, the LU 
completes the resync transaction before run- 
ning any other transaction programs’ that 
require sync point. The resync service TP is 
initiated by RM at some LU, typically at the 
sync point initiator; this TP attaches the 
resync TP at its partners, which continue 
propagating the resync TP throughout the LUs 


ee 
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that had been processing the distributed. _ 
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1. Function-shipping resource control recursively calls PS to communicate with the partner. 
The conversation used for communication with the partner has its own protection manager. 


2. PS components not relevant to sync point have been omitted from this figure. 
3. A distinct protection manager exists for each conversation resource created by PS. 


4. The non-SNA components are undefined protocol machines (UPMs). 


¢ Figure 2-28. Relationship of LU Components for Sync Point Functions 
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The first step of the resync transaction is 
to validate the integrity of the LU logs, 
1.e.» to determine that all LUs' logs contain 
consistent entries for the same LUW. To do 
this, the resync service TPs’ exchange 
Exchange Log Name GDS variables on the con- 
versation. Next, the service TPs exchange 


DATA STRUCTURES 
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The LU maintains data structures representing 
the state and configuration of its resources. 


Some system-definition data structure ele- 
ments represent the LU-accessed network 
resources. These structures describe the 
characteristics of the LU itself, the trans- 
action programs that the LU can run, the 
partner LUs with which the LU can communi- 
cate, and the modes characterizing possible 
sessions with particular partner LUs. 


Other data structure elements represent the 
dynamic environment created by the LU. The 
principal components of this environment are 
the transaction program instances in exe- 
cution (represented by transaction-program 
processes) the active sessions with other LUs 
(represented by half-session processes), and 
the active conversations (represented by con- 
versation resources). This environment also 
includes the relationships of the dynamic 
components to the  LU-accessed network 
resources and to each other. 


LU-ACCESSED NETWORK RESOURCES 


Figure 2-29. on page 2-41 illustrates the data 
structures that represent the LU-accessed 
network resources. 


The LUCB structure (and some associated lists 
not shown) describe the local LU. This 
information includes the LU's fully qualified 
name and the set of optional functions (e.g. ;, 
parallel sessions and mapping) that the LU 
supports. The LUCB is also the anchor for 
lists of data structures describing the other 
LU resources. 


A TRANSACTION_PROGRAM structure (and associ- 
ated lists not shown) describe the trans- 
action programs at the local LU. This 
information includes the transaction program 
name, its current availability status, and 
the set of optional functions (e.g.», sync 
point, mapping, and access control) that it 
supports. 


A PARTNER_LU structure describes a remote LU 
(potential partner LU). This information 
includes the remote LU's names: local LU 
name, fully-qualified LU name, and uninter- 
preted LU name. It also includes the set of 
the LU's optional capabilities, such as par- 
allel sessions and security. The PARTNER_LU 
structure also contains a list of mode 
descriptions. 


Peer Protocols 


Compare States GDS variables to determine the 
status of the sync point protocol at the time 
of failure. PS.SPS then uses this informa- 
tion to complete the sync point protocol. 
(See SNA Formats for the SNA-defined format 
of the Exchange Log Name and Compare States 
GDS variables. ) 


A MODE structure describes a set of session 
characteristics that a group of sessions 
share. These characteristics include the 
name of the mode and the set of optional 
functions that are supported by the remote LU 
on a mode basis, e.g.» sync point. It also 
includes the session parameters that charac- 
terize this mode, such as maximum allowed RU 
size, session-pacing window size, and session 
cryptography parameters. The MODE structure 
also indirectly describes link character- 
istics: the mode name is used by the control 
point as the key to tables identifying the 
links and routes to be used for sessions for 
that mode. Distinct partner LUs have dis- 
tinct modes. The characteristics for ses- 
sions to different partner LUs may be 
different even if the sessions have the same 
mode name. 


PROCESSES AND DYNAMIC RESOURCES 


Figure 2-30 on page 2-42 illustrates the 
principal data structures and processes, and 
their relationships, that represent the 
dynamic environment. The formal description 
represents these relationships in various 
ways such as pointers between control blocks, 
keys of elements in lists, and intermediate 
dynamic control blocks. 


The processes also contain state information 
used by LU functional components; this is 
described in more detail in chapters. con- 
cerned with the relevant functional compo- 
nents. 


The TP process represents a transaction pro- 
gram instance. It identifies the transaction 
program code that it 1s using. There may be 
multiple transaction program processes exe- 
cuting the same transaction program code. 


The HS process represents a half-session. It 
identifies the remote LU and mode with which 
it is associated. A mode may be associated 
with many half-session processes, but each HS 
process is associated with only one mode. 


The RCB structure represents a conversation 
resource. The RCBs are the central elements 
in the dynamic configuration of the LU: they 
represent the connection of a_ transaction 
program to a half-session; this connection is 
dynamically created and destroyed, and allows 
an asynchronous (Send/Receive) relationship 
between TP and HS. The RCB identifies the 
local TP using the conversation and the 
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LEGEND: 
Vertical lines represent lists of subordinate resources 


Associated Data Structure Name 
LUCB: LUCB PTNR: PARTNER_LU 
MODE: MODE TPGM: TRANSACTION_PROGRAM 


C) Figure 2-29. LU Static Data Structures (Example) 
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LEGEND: 
Vertical lines represent lists of subordinate resources 
association of process to static data elements 

#### association of processes via RCB dynamic data element 


t # 
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PTNR W 


PTNR X 
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**** association of RCB with MODE in lieu of unavailable HS 
Abbr. Data Structure Name 
LUCB: Local LU information LUCB 
TPGM: Transaction Program Code information TRANSACTION_PROGRAM 
PTNR: Partner LU information PARTNER_LU 
MODE: Mode information MODE 
TP: Transaction program process 
RCB: Conversation resource information RCB 
HS: Half-—session process 
Figure 2-30. LU Dynamic Data Structures and Processes (Example) 
half-session being used, if any. Because a 
session might not be immediately available 
when a TP allocates a conversation, the RCB 
also identifies the remote LU (PARTNER_LU) 
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and mode name (MODE) for the desired session. 
Many conversation resources, hence RCBs, may 
be associated with the same local TP, but 
each RCB may be associated with only one 


C > 


CY 


a \ 


, ee. 
‘i 


C | 
e. 


local TP, one partner LU, one mode, and one 


C half-session. 

4 Figure 2-30 on page 2-42 illustrates several 
of the possible relationships among these 
structures. In the figure: 


e §€©6©Active TP B for transaction program code 
2 has two active conversations: | 


_ RCB F connects it to remote LU W via 
session K with mode name U. 


- RCB G connects it to remote LU Y via 
session P with mode name V. 


6 LU W has two free sessions, M and N, each 
with mode name L. 


Remote LU X has a single mode name with 
no active sessions. 


( | e No active TP instances exists for trans- 
~~ action program 3. 


e Two active TP instances exist for trans- 
action program 4: TPs C and D. 


LU STARTUP AND SHUTDOWN 


LU startup consists of three phases: creat- 
ing the LU processes, initiating the control 
operator transaction program, and setting the 
LU definition and session limits. The LU 
then initiates programs and activates ses- 
sions in response to further operator, trans- 
action program, or partner-LU actions. 


. 
case 


To shut down the LU, the steps are reversed, 
but some can be = omitted. The minimum 
required to terminate communication is to 
reset the session limits. 


- LU PROCESS CREATION AND TERMINATION 


Figure 2-32 on page 2-45 shows the process 
creation and termination hierarchy for the 
LU. The node operator facility (NOF) creates 
the SM process. As part of SM's initial 
processing, it creates the RM process and 
then informs NOF of RM's successful creation. 
These processes continue running thereafter. 


The TP and HS processes are discussed in 
"Running State" on page 2-44. 


CONTROL-OPERATOR TRANSACTION PROGRAM INITI- 
ATION 


As a result of receiving a START_TP record 
: from NOF, RM creates a PS process and initi- 
& ates the control-operator TP. 
va 


° Two conversations G and H exist with 
remote LU Y, each using a different mode 
name. 


° Two conversations I and J use separate 
sessions R and T;, both with mode name Z. 


RESOURCE RELATIONSHIPS IN A DISTRIBUTED 
TRANSACTION 


In contrast to Figure 2-30, which illustrates 
the data structures for several transactions 
from the perspective of a single LU, Fig- 
ure 2-31 on page 2-44 illustrates the 
relationships among data structures” at 
several LUs from the perspective of a single 
distributed transaction. In this case, the 
paired half-sessions connect LUs, and the 
paired conversation resources, represented by 
RCBs, connect transaction program instances. 


CONTROL-OPERATOR ACTIONS 


The control operator specifies the LU defi- 
nition describing the LU-accessed network 
resources: the transaction programs, partner 
LUs, and modes. (An implementation might 
provide this function without requiring 
explicit operator interaction, e.g., the LU 
definition might be specified at 
system-definition time. ) 


The operator initializes session limits with 
the partner LUs by issuing the INITIAL- 
IZE_SESSION_LIMIT verb for the relevant mode 
names. For parallel-session mode names, this 
verb activates an LU-LU session using the 
SNA-defined mode name SNASVCMG (if not 
already active) and establishes mutually 
agreeable session limits for other mode names 
by exchanging CNOS GDS variables on that ses- 
sion. This verb optionally causes activation 
of a predetermined number of sessions for the 
specified mode name. | 


When sessions are to be deactivated, the con- 
trol operator issues RESET_SESSION_LIMIT for 
the mode name. For a parallel-session con- 
nection, this causes another CNOS GDS vari- 
able exchange to elicit the partner LU's 
cooperation in the session shutdown. In any 
case, this verb causes the LU to eventually 
cease initiating new transaction programs and 
activating new sessions (drain). As sessions 
become unused, RM and SM deactivate them. 


The LU initiates no further actions to shut 


down the LU. Any further actions are at the 
initiative of NOF. 
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Association of a process with its data structures 
Conversation (connection between transaction program instances [TPs]) 


Session (connection between LUs) 


Transaction program data structure (represents transaction program code) 
Resource control block (represents a conversation) 


Transaction program process instance 
Half—session process instance 


2-31. 


RUNNING STATE 


Once the LU-LU session limits have been set, 
the LU is ready to process transactions. 


RM creates a transaction-program process when 
it receives an Attach or an initial TP invo- 
cation request (START_TP); it destroys that 
process when PS indicates that the TP has 
completed and all its conversations have been 
deallocated. 


Peer Protocols 


response to UNBIND, 


Data Structure Relationships among LUs for a Distributed Transaction (Example) 


Either RM or the partner LU can request ses- 
sion activation; in either case, SM performs 
the relevant processing. SM creates an HS 
process for an LU-LU session and comects it 
to a path control instance whenever it sends 
or receives BIND. SM destroys that process 
when it has sent or received a positive 
has disconnected the 
half-session from path control (by sending 
PC_HS_DISCONNECT, RSPC(UNBIND), or UNBIND to 
the CP), and has notified the CP that the 
session is ended (by sending SESSEND_SIGNAL ). 


Transaction 
Program / 
Presentation 
Services 
Process 


Resources 
Manager 
Process 


(RM) 


~  NOFe———_—— 
C) Session @ 


Manager 
Process 


LU-LU 
Half—Session 
Process 


(SM) 


LEGEND: 
e > process creation (The arrow points from creator to created. ) 


a NOF: Node operator facility 


Figure 2-32. LU Process Creation and Termination Hierarchy 


EXAMPLE the local and remote LUs, respectively, for 
an LU shutdown sequence. "Chapter 5.4. Pres- 
entation Services--Control-Operator Verbs" 

Figure 2-35 on page 2-52 and Figure 2-36 on describes LU startup and shutdown in more 

page 2-53 illustrate typical interactions at detail. 
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PROTOCOL BOUNDARY SUMMARY 


This section lists the external message units INTERCOMPONENT STRUCTURES 
and internal records exchanged by LU compo- 

nents. See "Appendix A. Node Data Struc- 

tures" for full descriptions of these SM-CP Protocol Boundary 
structures. 


SM to CP Interprocess Signals 
TRANSACTION PROGRAM VERBS AND INTERPROCESS 


SIGNALS ASSIGN_LFSID 
ASSIGN_PCID 
FREE_LFSID 
PS-TP Protocol Boundary: Transaction Program INIT SIGNAL © 
Verbs LFSID IN USE RSP 
MU (contains the following RUs) 
BIND 
Basic-Conversation Verbs UNBIND 
Bye ae ee eee ioe RSP( BIND ) 
ALLOCATE RSP (CUNBIND ) 
CONFIRM PC_HS_DISCONNECT C- 
CONFIRMED SESSEND_SIGNAL ; 
DEALLOCATE SESSST_SIGNAL 
FLUSH 
GET_ATTRIBUTES CP to SM Interprocess Signals 
POST_ON_RECEIPT 
PREPARE_TO_RECEIVE ASSIGN_LFSID_RSP 
RECEIVE AND_ WAIT ASSIGN_PCID_RSP 
RECEIVE IMMEDIATE CINIT_SIGNAL 
REQUEST_TO_SEND INIT_SIGNAL_NEG_RSP 
SEND_DATA LFSID_IN_USE 
SEND_ERROR MU (contains the following RUs) 
TEST BIND 
UNBIND FON 
Mapped-Conversation Verbs RSP( BIND ) ( 
| SESSION_ROUTE_INOP Ne 
MC_ALLOCATE 
MC_CONFIRM 
MC_CONFIRMED SM-HS Protocol Boundary 
MC_DEALLOCATE 
MC_FLUSH 
MC_GET_ATTRIBUTES SM to HS Interprocess Signals 
MC_POST_ON_RECEIPT 
MC_PREPARE_TO_RECEIVE INIT_HS 
MC_RECEIVE AND _WAIT 
MC_RECEIVE_IMMEDIATE HS to SM Interprocess Signals 
MC_REQUEST_TO_SEND = 
MC_SEND_DATA . ABEND_NOTIFICATION e 
MC_SEND_ERROR ABORT_HS = 
MC_TEST INIT_HS_RSP 


Type-Independent Verbs 
SM-NOF Protocol Boundary 


BACKOUT 

GET_TP_PROPERTIES 

GET_TYPE SM to NOF Interprocess Signal 
SYNCPT 

WAIT RM_CREATED 


Control-Operator Verbs 
SM-BM Protocol Boundary 
ACTIVATE_SESSION 
CHANGE_SESSION_LIMIT 
DEACTIVATE_SESSION SM-BM Calls? 
INITIALIZE _SESSION_LIMIT 
PROCESS_SESSION_LIMIT 
RESET_SESSION_LIMIT 


Each buffer manager protocol boundary (here and following) is a synchronous (calling) invo- C 
cation of the buffer manager by the components of the LU; the names in the list refer to 
request identifiers modeled as parameters in the Call. 
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_ADJUST_POOL 
FREE_BUFFER 
GET_BUFFER 
RESERVE_BUFFER 


HS-PC Protocol Boundary 


HS to PC Interprocess Signal 
MU( outgoing data) 
PC to HS Interprocess Signal 


MU( incoming data) 
-HS-BM Protocol Boundary 


HS-BM Calls 


ADJUST_POOL 
FREE_BUFFER 
GET_BUFFER 
TRANSFER_BUFFER 


PS-HS Protocol Boundary 


PS to HS Interprocess Signals 


CONFIRMED 
REQUEST_TO_SEND 
MU(SEND_DATA_RECORD } 
SEND_ERROR 


HS to PS Interprocess Signals 


CONFIRMED 

MUC incoming data) 
RECEIVE _ERROR 
REQUEST TO SEND 
RSP_TO_REQUEST_TO_SEND 


PS-RM Protocol Boundary 


PS to RM Interprocess Signals 


ABEND_NOTIFICATION 
ALLOCATE_RCB 
CHANGE_SESSIONS 
DEALLOCATE_RCB 
GET_SESSION 
RM_ACTIVATE_SESSION 
RM_DEACTIVATE_SESSION 
TERMINATE_PS 
UNBIND_PROTOCOL_ERROR 


RM to PS Interprocess Signals 


MU( FMH-5 ) 
CONVERSATION_FAILURE 
RCB_ALLOCATED 

RCB DEALLOCATED 
RM_SESSION_ACTIVATED 
SESSION_ALLOCATED 
START_TP 


PS-BM Protocol Boundary 


PS-BM Calls 


FREE_BUFFER 
GET BUFFER 


RM-HS Protocol Boundary 


RM to HS Interprocess Signals 


BID_RSP 
BID_WITHOUT_ATTACH 
BIS REPLY 

BIS RQ 

BRACKET FREED 
ENCIPHERED_RD2 
HS_PS_CONNECTED 
RM_HS_CONNECTED 
RTR_RQ 

RTR_RSP 
YIELD_SESSION 


HS to RM Interprocess Signals 
BID 
BID RSP 
BIS_RQ 
BIS REPLY 
FREE SESSION 
MU(FMH-5 or FMH-12) 


RTR_RQ 
RTR_RSP 


RM-SM Protocol Boundary 


RM to SM Interprocess Signals 
ABEND_NOTIFICATION 
ACTIVATE_SESSION 
DEACTIVATE_SESSION 

SM to RM Interprocess Signals 
ACTIVATE_SESSION_RSP 


SESSION_ACTIVATED 
SESSION_DEACTIVATED 


RM-Initiator Process Protocol Boundary 


RM to Initiator Process Interprocess Signal 
START_TP_REPLY 


Initiator Process to RM _ Interprocess 
Signals 


SEND_RTR 
START_TP 


RM-BM Protocol Boundary 


RM-BM Calls 


FREE_BUFFER 
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The following figures illustrate both the 
internal protocol-boundary sequence flows 
among LU components and the external flows 
between two LUs that result from 
basic-conversation verb issuances. 


Each flow is illustrated by a pair of figures 
on facing pages. Each separate figure 
represents the complete flow as seen by a 
single LU. The figure labeled local LU 
represents the LU that initiates the sequence 
being illustrated; the figure labeled remote 
LU represents the partner LU. For cases 
illustrating a race between two LUs, the LUs 
are distinguished as first speaker (FSP) and 
bidder. The flows through the path control 
network are shown in the column nearest the 
center margin, and are replicated in each 
figure; numerals in parentheses in the mar- 
gins between facing parts of the same flow 
correlate corresponding steps in the facing 
figures. When flows cross in the 
path-control network, the crossing is illus- 
trated on the sending side of the delayed 
flow. 


NOTATION 


For the interpretation of labels on the 
arrows, see the following (which, in some 
cases have been abbreviated): 


e For verb and verb-parameter names 
(TP-PS), SNA Transaction Programmer's 


° For protocol-boundary records and message 
units (TP-PS, PS-RM, RM-SM), "Protocol 
Boundary Summary" on page 2-46 


e For RU names (SM-SM, HS-HS), SNA Formats 


e For RH indicators 


Formats 


(SM-SM, HS-HS), SNA 


The following abbreviations for chaining 
indicators are also used: 


_ FIC (first in chain) = (BC,-EC) 


Peer Protocols 


- MIC (middle in chain) = (-BC,-EC) 


- LIc (last in chain) = (-BC, EC) 


- OIC (only = in chain) = (BC, EC) 
e For data elements of RUs (SM-SM, HS-HS), 


SNA Formats 


In cases where a component returns parameters 
in a verb, the parameters (e.g., RC), but not 
the verb, are named on the flow arrow. 


The following conventions and abbreviations 
apply to all sequence flows in the book. 


o—————>o asynchronous (send/receive logic) 
intercomponent flow 

o——o——>o asynchronous (send/receive logic) 
intercomponent flow with 
intermediate-component processing 

o- — — —>o creation or destruction of a 
process (action shown in 
parenthesis) or synchronous 
(call) invocation of another 
component (e.g., the buffer 
manager ) 

{ } Braces surrounding alternatives 
indicate inclusion required. 

[ ] Brackets surrounding alternatives 
indicate inclusion optional. 

-. or Ellipses indicate possible 
repetitions or unshown 
: continuations. 

ASM CP address space manager 

BM buffer manager 

cP control point 

HS half session 

IP initiator process 

LU logical unit 

NOF node operator facility 

PC path control 

RM LU resources manager 

SM LU session manager 

SS CP session services 


Numbers to the left of the flows correspond 
to enumerated annotations in the text outside 
(usually following) the figures. Footnotes 
appear in some figures to relate minor points 
such as signal omissions or simplification. 


6S 
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OE a a a 8 NOUR SP) (to partner LU) ( 
ALLOCATE (WHEN : 


SESSION_ALLOCATED}. ALLOCATE_RCB ? . ° 


; .RCB_.ALLOCATED( OK ) | : : 
‘ o< , 

: | GET_SESSION .ACTIVATE_SESSION ! . BIND? - 

; >o————__>o— > (a) 


: ; ; 1 .  +RSP(BIND )2 
; ; : Oo ——_ (hb) 


F ; [INIT_HS ; 

r ‘ >o 

: . ACTIVATE_ . INIT_ | crv> 
: , . SESSION_ . HS_ > (c) 
. RC=OK SESSION_ALLOCATED( OK) RSP( +) . RSP(+) . = #RSP(CRV)> | 
Os - - - e-em Ke oO O_O  —_ (ds) 


RM_HS_CONNECTED 


ENCIPHERED_RD24 . BC»-EC,RQE1,-BB,FMH-124 a. 
>a (ee) Nes 
HS_PS_CONNECTED : 
P >O 
SEND_DATA MU( FMH—-5,data,NOT_END_OF_DATA). . _-5BC,RQE1,FMH-5,data 
ae eee a > , >_> (1) 
RC=OK | 
o<- ~~ - - - ~ - 
7 | nS 
SEND_DATA MU(data,NOT_END OF DATA)... RQE1,data ar 
Sai eee Emenee lee aloe rene REE, eg 5, 
RC=OK | 
o- = - - ---- 
| necexve_ano_waxt MU(data,PREPARE_TO_RCV_FLUSH) . EC ,RQE1,CD,data 
ig alee ‘ , ae ee Seam Ay 
‘i S 
mee 
.RC=OK 
.WHAT_RECEIVED= 
DATA_COMPLETE . MU(data;DEALLOCATE_FLUSH) . .  _BC,>EC,RQE1,CEB,data 
eed ee ee ate a eG 


| RECEIVE_ANO_WATT s..° : FREE_SESSION . | 
-—------- >o o<- 


ae aes ee eee ae 


DEALLOCATE(LOCAL) . DEALLOCATE_RCB 


Notes: | 
T’Session-activation flows to CP and path control have been omitted; 
see "Chapter 4. LU Session Manager" for details. Buffer manager calls have been omitted. 
2 BIND/RSP(BIND) flows through the CP (not shown). 
3 CRV/RSP(CRV) flows only when session-level cryptography is being used. | 
4 Flows only when LU-LU verification is being used. C 
/ 


Figure 2-33. Complete Conversation Example--Local LU 
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C) 


(to partner LU) 


BIND@ 
(a) 


cRV> 
(c) 


¢ BC ,-EC,RQE1,-BB,FMH-12* 


(e) 


~BC »RQE1,FMH—-5,data 
(1) 


za f 
C) . 
“ RQE1,data ; 


(2) 


EC,RQE1,CD,data 
(3) 


BC »EC »RQE1 »CEB »data 
(4) < 


Notes: 


(Bidder JHS SM RM PS TP 


Pe) e e e 


+RSP( BIND )@ : | : ; : 
(b) < 1 ; . F 


sINIT_HS | : : 


Pie) ° e e e 


| RSP(+) .SESSION_ACTIVATED . . : 
>-o- OF>"p 


: RM_HS_CONNECTED | ‘ ° 
o< 


MU( FMH-12 )4 ; ; : 
>On nn ne eee 0 t) 


+RSP(CRV)> | INIT. . : ; Z 
(d) < HS ; : 


‘ BID. ‘ ;. ° 
>On OO OOO PCO ‘ ° 
‘ BID_RSP( +) | ° < 
o< ° ° 
| MU( FMH—5 ) ‘ MU( FMH—5 ) ° (initiate) ; 
> —_—_————_—_—_—~=XVOOO—" OO Ow ww wr NM eK = >o 


RECEIVE_AND_WAIT 


. HS_PS_ CONNECTED | ; 
o< o- - ------ 


. : RC=OK »NHAT_RECEIVED= 
MU( data ,NOT_END_OF_DATA) DATA_INCOMPLETE 
a >o 


RC=OK »,WHAT_RECEIVED= 


MU( data »PREPARE_TO_RCV_FLUSH) . DATA_COMPLETE. 
>o—_—_—— rr a ee eee >o 
. RECEIVE_AND_WAIT 
o- ------- 


RC=OK > . 
WHAT_RECEIVED=SEND. 


, eam om ee ene eee ee >o 
MU( data,NOT_END_OF_DATA) SEND_DATA | 
o< Oi ir er re ee 
RC=OK : 
; © Ren ee ee ee eee >o 
MU( data ,DEALLOCATE_FLUSH ) -DEALLOCATE( FLUSH) | 


o- ------- 


. DEALLOCATE_RCB | 

o< 

| RCB_DEALLOCATED . RC=OK ; 
>Oo- ~m~ r- TT Km KK - >o 


>o ; e 


é BRACKET_FREED | ‘ ‘ 
o< 


o< 


FREE_SESSION 


T’Session-activation flows to CP and path control have been omitted. 

2 BIND/RSP(BIND) flows through the CP (not shown). 

> CRV/RSP(CRV) flows only when session-level cryptography is being used. 
4 Flows only when LU-LU verification is being used. 


Figure 2-34¢.. Complete Conversation Example--Remote LU 
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COPR TP. PS 
RESET_SESSION_LIMIT? 
O-------- >o 


‘RM SM —__HSCFSP) (to partner LU) 


. (if parallel session, CNOS exchange occurs here) 


o< 


. CHANGE_SESSIONS® . 


° aac” 


Repeat for 
each session < 
for the 

speci fied 
mode name. 


Notes: 


> (x) 
(drain action)* : | 
‘ BIS_R@Q BIS,RQ,BC,EC ,RQE1,-BB,-CEB 
0 1) 
- BIS_REPLY BIS,RQ,BC ,EC,RQE3,-BB,-CEB 
eC nanan ntennnnnerremnenneaenmemcenane  } 


locactavare_sessron 4 UNBIND® 


> > (a) 
; : +RSP( UNBIND )5 
: 4 <b) 


For specific-session deactivation, substitute DEACTIVATE_SESSION and eliminate the CNOS exchange. 
For specific-session deactivation, substitute RM_DEACTIVATE_SESSION and eliminate the drain action 
Drain action: wait until no allocation requests, allowed by drain state, are pending, 


then wait until session is in between-brackets state, i.e., #+RSP(CEB) is sent or received. 


> 


Session-deactivation flows to CP have been omitted. 
UNBIND/RSP(UNBIND) flows through the CP (not shown) 


Figure 2-35. Session Deactivation--Local LU 
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a, 
2 


a 
< 


) 


Ej (to partner LU) (Bidder HS SM RM pS CNOS TP 


(if parallel session, CNOS exchange occurs here) % ‘ ; 
0 
BIS,RQ,BC ,EC,RQE1 ,-BB,-CEB. BIS_RQ . 
(0 I) ne 6° ed 
F , (drain action)* 
BIS,RQ,BC ,EC ,RQE3 »~BB,-CEB. BIS REPLY ‘ Repeat for 
C2 0 OO OO > each session 
‘ ; : in the mode. 
UNBIND® ; . SESSION_DEACTIVATED 
 (F-- |) | 6 ° ae A) 
me +RSP(UNBIND )5 : | 
< ,  (b) < _ 
of 


Notes: 
> Drain action: wait until no allocation requests allowed by drain state are pending, 
then wait until session is in between-brackets state, i.e., +RSP(CEB) is sent or received. 
4 Session-activation flows to PU and CP have been omitted. 
5 UNBIND/RSP(UNBIND) flows through the CP (not shown). 


Figure 2-36. Session Deactivation--Remote LU 
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an ee 
TP PS RM HSC FSP ) (to partner LU) = 


: -RCB_ALLOCATED(OK) | : 
° o< ‘ 
‘ | GET_SESSION - HS_PS_ CONNECTED . 
° >On ee 0 
- RC=0K SESSION_ALLOCATED( 0K }| é 
Om wm KM nmr KK KK o< 


SEND_DATA ; 
Sore er Gere NTR one ee ey oe 70 ° e 
e RC =OK e e 
hapics eae J ) : 
CONFIRM ‘ MU( Attach,data »,CONFIRM ) .OIC ,BB,RQD2|3,FMH-5,data 


Se TT) 


° e e 


RC=OK ; CONFIRMED ae : +RSP 
o- -------- $$ i (2) 


Figure 2-37. ALLOCATE(RETURN_CONTROL=WHEN_SESSION_ALLOCATED), CONFIRM (by First Speaker )--Local LU Su 
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C (to partner LU) HS( Bidder } RM PS TP 


OIC,BB,RQD2|3,FMH-5!,data . BID : ; 
QQ) 7 0 : ; 


.  BID_RSP(+) | 

o< ‘ 

| MU( Attach!,data). MU(Attach,data) . (initiate) J 
oa aS es as a a ee Nee lees >o 


( ; . HS_PS_CONNECTED | . RECEIVE_AND_WAIT 
a o< o< esiigis: ‘gama Seem’). ate (1 Gey? ~ map > aoe Se 


. RC=OK »WHAT_RECEIVED= 
MU( data ,CONFIRM ) ‘ DATA_*COMPLETE 
2Or ~ rrr rer >o 


: . RECEIVE_AND_WAIT 
. OS Se SS 

; RC=OK ,WHAT_RECEIVED= 

. L CONFIRM 

; we Ea nee ee eee >o 

+RSP : CONFIRMED , CONFIRMED | 
CQ SS He ee 


Note: 
ae aaa 


1 The FMH-5 contains the Attach 


Figure 2-38. ALLOCATE(RETURN_CONTROL=WHEN_SESSION_ALLOCATED), CONFIRM (by First Speaker )--Remote LU 
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Figure 2-39. ALLOCATE(RETURN_CONTROL=WHEN_SESSION_ALLOCATED), RECEIVE_AND_WAIT (by Bidder )--Local LU 
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PS RM HS( Bidder ) (to partner LU) 
ALLOCATE . ALLOCATE_RCB. . 
—-— eee we Dp eee SE} . 
RCB_ALLOCATED( OK) | 
o< ‘ 

| GET_SESSION BID_WITHOUT_ATTACH. — LUSTAT,BB,RQD1 | 
ig 
= SESSION ALLOCATED(OK) BID_RSP(+) +RSP 


ee eS: Ses yeas eas eee eae Vaal nk OUR OO ( 2 ) 


SEND_DATA . HS_PS_CONNECTED . 
--e-e---- >o >o 


RECEIVE_AND_WAIT .MU(Attach,data,PREPARE_TO_RCV_FLUSH). OIC,RQE1,CD,FMH-5,data 


> 8) 
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i 


aa 


> 


NX. ue 


C (to partner LU) 


LUSTAT >BB ,»RQD1 


+RSP 


OIC ,RQE1,CD,FMH-5,data 
(3) 


HS( FSP ) RM PS TP 


. BID : 


.  BID_RSP(+) | 
o< 


MU(Attach,data) . (initiate) 
. HS_PS_ CONNECTED | . RECEIVE_AND_WAIT 
o< OSS SS SS ee 


. RC=OK ,WHAT_RECEIVED= 
MU( data »,PREPARE_TO_RCV_FLUSH) : DATA_COMPLETE 
207 ~~ - Ter eC >O 


; : . RECEIVE_AND_WAIT 
° 0 = SS Se 

e e RC=0K > 

: . WHAT_RECEIVED=SEND 
eee ee esate >o 


Figure 2-40. ALLOCATE(RETURN_CONTROL=WHEN_SESSION_ALLOCATED), RECEIVE_AND_WAIT (by Bidder )--Remote 


LU 


Chapter 2. Overview of the LU 


2-57 


a 
TP. PS RM HS( Bidder ) (to partner LU) os C } 


ALLOCATE ‘ ALLOCATE_RCB : . 
Oo~- - ------- —_—_—- "70 4 
é RCB_ALLOCATED( OK ) | ‘ 
- o< ‘ 
GET_SESSION BID_WITHOUT_ATTACH. LUSTAT ,BB »RQD1 
5 Oi errr rmemtenaremeneenimaneimnnaannarmeemnenanmnannemnencnt > ( JT} 
RC=0K SESSION_ALLOCATED( OK ) BID_RSP( +) ar | +RSP 
O<— — - - SO OO OOOO nn Oa eee «(2 ) 


SEND_DATA | HS_PS CONNECTED . 

—--—------ >o >o 
° RC= e : e 
ces J 


CONFIRM MU( Attach, data ,CONFIRM) .  OIC,RQD2|3,FMH-5,data 
0-—$—$ > (3) 


. aa 
‘ RECEIVED_ERROR ‘ —-RSP( 0846 ) . | 
————— ee es Gj we 

RC=ALLOCATION_ERROR. MU( FMH—7 »data?,DEALLOCATE_FLUSH ) ‘ OIC ,CEB,RQE1,FMH—7 ,data? 

Sas a ek a es 6) 


DEALLOCATE( LOCAL) DEALLOCATE_RCB FREE_SESSION | | 
Pe a pe eas eae >o—————— 0K 


. RC=OK . RCB_DEALLOCATED | BRACKET_FREED . 
os- - = - - - HK o< ° 


Note: | —_ 
T' Optional log data \ | 
—, 
Figure 2-41. ALLOCATE( RETURN_CONTROL=WHEN_SESSION_ALLOCATED), CONFIRM (by Bidder), Attach Error 
~-Local LU i | 


C > 
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& 


(to partner LU) HSCFSP ) RM PS 
LUSTAT ,BB ,RQD1 . BID . % 
QOD —_—_—_—_—_—_—_—_—_—_—_—_—_—_———rn—n—— On On eee 


+#RSP : BID_RSP( +) | : 
2 


: . MUCAttach,data, 
OIC ,RQD2|3,FMH-5,data . MUCAttach,data) . error sense code). 
(3) —_,__—_—_—_—_—_—_—_—_—_—--,_oO eS eee Oe ee eee 


. HS_PS_CONNECTED | 
o< 


MU( data ,CONFIRM). 


—RSP( 0846 ) 
QC 


SEND_ERROR 


OIC ,CEB,RQE1,FMH—-7,data!. MU(FMH-7,data!,DEALLOCATE_FLUSH) 
C5 eee — 


! FREE_SESSION . DEALLOCATE_RCB | 
>o< 

- BRACKET_FREED | RCB_DEALLOCATED. 

o< >O 


Note: 
T Optional log data 


Figure 2-42. ALLOCATE( RETURN_CONTROL=WHEN_SESSION_ALLOCATED), CONFIRM 
Error--Remote LU 
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TP 


(by Bidder), 
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Tl S—“‘“CS™SCSC*RMCC‘“C(#’CCCMS( FSP) ite par crer. 10) « CC 


- ALLOCATE ALLOCATE_RCB( immediate ) . 
(oi > —0 ‘ 
: FSP session available ; 


- RC=OK -RCB_ALLOCATED( OK } | : . 
O<m wm ww eww eK K = o< 


é HS_PS_ CONNECTED . 
4 Pie) 


[The flow continues as in the ALLOCATE( RETURN_CONTROL=WHEN_SESSION_ALLOCATED) case. ] 


Figure 2-43. ALLOCATE(RETURN_CONTROL=IMMEDIATE), Successful--Local LU 
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e 


(to partner LU) HS RM PS TP 


Figure 2-44. 


(no activity at remote LU) 


from here on just like ALLOCATE(RETURN_CONTROL=WHEN_SESSION_ALLOCATED ) 


ALLOCATE ( RETURN_CONTROL=IMMEDIATE ), Successful--Remote LU 
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TP PS RM HS 
- ALLOCATE . ALLOCATE_RCB( immediate ) ‘ 
O- --- eee -- > 0 : 
‘ : (no first—speaker ‘ 
, ; session available) ‘ 


Figure 2-45. 


RCB_ALLOCATED 
. RC=UNSUCCESSFUL . (unsuccessful ) 
OM~ ~K—- K- KK K~ - = o< 


ALLOCATE ( RETURN_CONTROL=IMMEDIATE ), Unsuccessful--Local LU 
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(to partner LU) 


& (to partner LU) HS RM PS TP 
(no activity at remote LU) 


Figure 2-46. ALLOCATE(RETURN_CONTROL=IMMEDIATE ), Unsuccessful--Remote LU 


C) 
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TP | PS RM HS (to partner LU) 
-DEALLOCATE( FLUSH) . MU( DEALLOCATE_FLUSH ) re LIC ,CEB,RQE1 


.  FREE_SESSION | 

o< 
DEALLOCATE_RCB ° 
>o e 


- RC=OK - RCB_DEALLOCATED BRACKET_FREED P 
O<— ee ew ee ee o< | > 


oO 


Figure 2-47. DEALLOCATE( TYPE=FLUSH) (RQE1)--Local LU 
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SNA LU 6.2 Reference: Peer Protocols 


a ~~ 


Tere 


= (to partner LU) HS RM PS TP 


: . RECEIVE_AND_WAIT . 

: : os eee eK KH —-O 

LIC ,CEB,RQE1 .  RCVD_DATA(DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL 

QQ ———— 0-H >o 


| FREE_SESSION - DEALLOCATE_RCB DEALLOCATE_LOCAL 
Sh Cat is as ee 


- BRACKET_FREED RCB_DEALLOCATED. RC= ‘ 
o< 


Figure 2-48. DEALLOCATE(TYPE=FLUSH) (RQE1)--Remote LU 
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aoa) 
TP PS RM HS (to partner LU) q : 
; . ‘ (sequence number wrap 
-DEALLOCATE( FLUSH) . MU( DEALLOCATE_FLUSH ) : LIC ,CEB,RQD1?2 
or = Se Se = = —_—_—_—_—_—_————nn nn eee > ( ] ) 
: - FREE_SESSION ; +RSP 
. o< OC (2) 
. DEALLOCATE_RCB 6 ; 
. 7O ° 
- |RC= - RCB_DEALLOCATED | BRACKET_FREED. . 
f= SS SS SSS = o< 7o 
NOTES: 


1 RQD1 is required under certain sequence number wrap conditions. 


Figure 2-49. DEALLOCATE(TYPE=FLUSH) (RQD1)--Local LU 
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(to partner LU) HS RM PS TP 
: . - RECEIVE_AND_WAIT . 
: . OSS SS Se oO 
LIC ,CEB,RQD1 : MU( DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL. 
CL) 0-H - He >o 
+RSP | - DEALLOCATE_RCB DEALLOCATE_LOCAL 
(2) < : o< o- - - mee HH 


Figure 2-50. 


Co 


O) 


| FREE_SESSION ; 

>O - ° 
- BRACKET_FREED RCB_DEALLOCATED. RC=OK : 
o< 2O- ~- e-em Kr Om Ore 


DEALLOCATE( TYPE=FLUSH) (RQD1)--Remote LU 
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TP PS | RM HS (to partner LU) | C ; 


SEND_DATA MU( data »NOT_END_OF_DATA) . FIC,data 
Cee ee ae ee SSS SS Se ee (CT) 
e RC= e e 
o< eS a ee J e e 
DEALLOCATE( FLUSH). MU( data ,DEALLOCATE_FLUSH ) . LIC,CEB,RQE1,data 
—~-------- > > 
: . FREE_SESSION | 
e o< 
. DEALLOCATE_RCB._. ‘ —RSP (0846 ) 
‘ >o —_——————— (2) 
‘ , (This stray response 
° , is discarded) — > (3) 
. RCS . RCB_DEALLOCATED BRACKET_FREED . 
oS = SSS Se = —o< >O ™ 
Figure 2-51. DEALLOCATE(TYPE=FLUSH) (RQE1), SEND_ERROR, -RSP Sent--Local LU C > 


Ga 


. al 
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| 
C) 


* 


(to partner LU) HS RM PS TP 
: ; . RECEIVE_AND_WAIT . 
‘ ; OM me em Ke KM a) 
FIC,data : MU( data ,NOT_END_OF_DATA) . RC=0K, : 
CL 0. ~ WHAT_RECEIVED= 
: : | DATA_INCOMPLETE . 
‘ ee >o 
—RSP( 0846 ) : SEND_ERROR . SEND_ERROR 

CQ OEE 
LIC ,CEB,RQE1,data ; MU( data ,DEALLOCATE_FLUSH) RC=DEALLOCATE_NORMAL 
3) —§ —— >o 


(purge data) 
FREE_SESSION - DEALLOCATE_RCB - DEALLOCATE( LOCAL ) 
>0< 00 RK mK mK Kr Ke eK 
- BRACKET_FREED | RCB_DEALLOCATED. RC= j 
o< 20e- — We nmr em >o 


Figure 2-52. DEALLOCATE(TYPE=FLUSH) (RQE1), SEND_ERROR, -RSP Sent--Remote LU 
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TP PS RM HS (to partner LU) 


- SEND_DATA : MU( data »,NOT_END_OF_DATA) . FIC,data 
Oo -------- eee 
- RC= ; é 
ae es a | . 
DEALLOCATE( FLUSH). MU( data ,DEALLOCATE_FLUSH ) . LIC,CEB,RQEl,data 


. FREE_SESSION | 
o< 


DEALLOCATE_RCB. : 
e >o 


RC= - RCB_DEALLOCATED BRACKET_FREED. 


Figure 2-53. DEALLOCATE(TYPE=FLUSH) (RQE1), SEND_ERROR, -RSP not Sent--Local LU 
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C 


< | 
ae 


(to partner LU) 


FIC,data 
(1) 


LIC ,CEB,RQE1,data 
(2) 


HS RM PS TP 
; ‘ . RECEIVE_AND_WAIT . 
: ; o- ------- -o 
‘ MU( data »,NOT_END_OF_DATA } . RC=OK, : 
> eee 0: WHAT_RCVD= ‘ 
: ‘ DATA_»*COMPLETE . 
. Be ee Rm RSS a ee rie >o 
‘ MU( data ,DEALLOCATE_FLUSH ) 
>o—— 0 
| FREE_SESSION ‘ .  SEND_ERROR 
>o o<- ------- 
- ‘ (purge data) : 
‘ RC=DEALLOCATE_NORMA 
ai Rs a tes eee ig an ne >o 


- DEALLOCATE_RCB »DEALLOCATE( LOCAL ) 
—_—_—_—_——————O0<- 


- BRACKET_FREED RCB_DEALLOCATED. RC= . 
o< 20e- ~ m~ Ke eK eK Ke >o 


Figure 2-54. DEALLOCATE(TYPE=FLUSH) (RQE1), SEND_ERROR, -RSP not Sent--Remote LU 
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TP PS RM HS (to partner LU) 

DEALLOCATE( CONFIRM). MU( DEALLOCATE_CONFIRM ) F EC,CEB,RQD2|3 

eo -------- > > 1) 
‘ CONFIRMED Fe +RSP 


| DEALLOCATE_RCB .- FREE_SESSION | 
>o< 


RC= - RCB_DEALLOCATED BRACKET_FREED 


Figure 2-55. DEALLOCATE( TYPE=CONFIRM) (RQD2|3)--Local LU 
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= (to partner LU) 


EC ,CEB,RQD2|3 
(1) 


+RSP 


HS RM PS TP 
, . . RECEIVE_AND_WAIT 
° ° oS = SS -O 
; : RC=OK ,WHAT_RECEIVED= 
; MU( DEALLOCATE_CONFIRM) ~, CONFIRM_DEALLOCATE 
C—O am ae ee >o 
: CONFIRMED . CONFIRMED | 
QO i i ee ee 


| FREE_SESSION : RC= 
>o 


—_— oe eee ee >oO 
: - DEALLOCATE_RCB -DEALLOCATE( LOCAL ) 
‘ OS OO ee Ke 
. BRACKET_FREED | RCB_DEALLOCATED .  RC= 
o< 2or- mH wer wr ew ee >o 


Figure 2-56. DEALLOCATE( TYPE=CONFIRM) (RQD2|3)--Remote LU 


“ 


———" 


O 
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TP PS 


. DEALLOCATE dk 
. (CABEND_PROG) 


RM 


: | DEALLOCATE_RCB . FREE_SESSION 
e > 


| . RCB_DEALLOCATED | BRACKET_FREED . 
OS SS eS eS o< > 


Note: 
TOptional log data 
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Figure 2-57. 
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HS 


e] 


(to partner LU) 


+RSP 


~ 


MU( FMH—7 ,data!,DEALLOCATE_FLUSH) .OIC,CEB,RQD1,FMH—-7( 0864) data? 


DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE, Between-Chain State--Local LU 


CU 


C) 


(to partner LU) HS RM PS TP 
Z ‘ - RECEIVE_AND_WAIT . 
; : o<—- -—-------o 
: . RC=DEALLOCATE_ 
OIC ,CEB,RQD1,FMH7( 0864) ,data?. MU( FMH-7 » data? ,DEALLOCATE_ FLUSH) . ABEND_PROG 
+ - - ee >o 


+RSP | fiancee aa RCB . neeeeen 
2 A «0 OY in 


_BRACKET_FREED | FREED : : 
Phir a ae 


Note: 


T'Optional log data 


Figure 2-58. DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE, Between-Chain State--Remote LU 
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PS RM HS (to partner LU) | 


FIC »>data 


Mu( data ,»NOT_END_OF_DATA) 


DEALLOCATE . 
( ABEND_PROG) : 


LIC ,CEB,RQD1 ,FMH—7( 0864 ) 

> :—sO038) 
- FREE_SESSION . +RSP 

DO nO eee «(4 ) 


RC= | . RCB_DEALLOCATED BRACKET_FREED. 
CHK eH ere ee —o< 70 


DEALLOCATE_RCB 
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Figure 2-59. 


DEALLOCATE( TYPE=ABEND_PROG ) 
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Peer Protocols 


Issued in SEND_STATE, In-Chain State--Local LU 


) 


fe 


ae aa , 


a 
\ 


Ne” 


(to partner LU). HS RM PS TP - 
° : - RECEIVE _AND_WAIT . 
. . CSS Se Se See e] 
FIC,data . MU( data ,NOT_END_OF_DATA) RC=OK ,WHAT_RECEIVED= 
DD SSS DATA_INCOMPLETE 
. . | b-------- >o 
. . - RECEIVE _AND_WAIT 
. . OSS SS SS Ss 
: . RC=OK ,WHAT_RECEIVED= 
RQE1,data . MU( data ,NOT_END_OF_DATA) ; DATA_INCOMPLETE 
LS 8 roe Se ee ee Se SS 20 
. . . RECEIVE_AND_WAIT 
. ° = SS SS SSS 
: : - RC=DEALLOCATE_ . 
LIC ,CEB,RQD1 »,FMH—7( 0864 ) . MU( FMH—7 »DEALLOCATE_ FLUSH ) . ABEND_PROG . 
SS = Oe Oe ie ee ee >O 


+RSP | ; eee 2 _RCB., SD algae di eaccoe 
(4) < MQ exe - - - - 


: _BRACKET_FREED | FREED ° ° 
eee | ° ° 


Figure 2-60. DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE, In-Chain State--Remote LU 
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TP PS RM HS (to partner LU) 
. SEND_DATA : . 
Qn se eee ee se ee ae >o e e 
. RC= : . 
0S SS _ : . 
. FLUSH MU( data ,NOT_END_OF_DATA) . FIC,data 
oO -------- >0—$—$ $i? > 11) 
ieee J . . 
MU(RECEIVE_ERROR ) eo. 4 —RSP( 0846 ) 
O.-—O e O  eee §(2 ) 
DEALLOCATE : ‘ ‘ 
( ABEND_PROG ) Z MU( FMH—7 ,data!,DEALLOCATE_FLUSH) . LIC ,CEB,RQD1,FMH—7( 0864) ,data? 


é | DEALLOCATE_RCB - FREE_SESSION | 
e >o< 

- RC=0K . RCB_DEALLOCATED | BRACKET_FREED ‘ 
Oe gg ggg Kee o< >o 


Note: 
TOptional log data 


Figure 2-61. DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE, -RSP Received State--Local LU 
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C, (to partner LU) HS RM PS TP 


; : . RECEIVE_AND_WAIT . 

: : oe ~~~ -----0 

: : RC=OK »NHAT_RECEIVED= 

FIC,data ‘ MU( data »NOT_END_OF_DATA) . DATA_INCOMPLETE . 

Cg rp >o 
—RSP( 0846 ) : SEND_ERROR .  SEND_ERROR 


C2 eee 


LIC ,CEB,RQD1,FMH-7(0864) . MU(FMH-7,data?,DEALLOCATE_FLUSH) RC=DEALLOCATE_NORMAL 
3) rr - - - - - - >0 


. (purge ) 
FREE_SESSION - DEALLOCATE_RCB. DEALLOCATE 
>O<——— ir i eK 
- BRACKET_FREED | RCB_DEALLOCATED. RC= . 
o< 20-7 eee >o 


* Notes: 


1 Optional log data 


This TP gets no indication that the DEALLOCATE is of type ABEND 
because everything (including FM headers) is discarded when purging. 


Figure 2-62. DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE, -RSP Received State--Remote LU 
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TP PS RM HS 7 (to partner LU) 
.  SEND_DATA Z MU( data ,NOT_END_OF_DATA) . FIC,data 
o--------- 29 1) 
RC= e e 
o< ae ae a eae ee J ° ° 
DEALLOCATE os | : ; 
( ABEND_PROG ) ‘ MU( data, FLUSH) - RQE1, data 
-------- > OO 2) 


| MU( FMH-7 ,DEALLOCATE_FLUSH ) . LIC,CEB,RQD1,FMH-7(086¢) | 
>. (3) 


; a | veatiocare_rcs -. FREE_SESSION : —RSP( 0846 ) 
" C—O OL ee Oe GD 


RC= - RCB_DEALLOCATED BRACKET_FREED 
0 SS ee Se o< : >o 


Figure 2-63. 
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DEALLOCATE( TYPE=ABEND_PROG) Issued in SEND_STATE Crossing SEND_ERROR--Local LU 


C (to partner LU) HS RM PS TP 


: 3 : - RECEIVE_AND_WAIT . 

° . 0 SS eS eS -o 

FIC,data a ° * MU( data ,NOT_END_OF_DATA) RC=OK ,WHAT_RECEIVED= 

lOO OO rr 0———(iés«éAATTAINCOMPPLTE 

: : L-------- >o 

—RSP (0846 ). SEND_ERROR . SEND_ERROR | 
ey ee 


RQEl; : MU( data ,NOT_END_OF_DATA) : ° 
(2) 0 | ° 
é (purge data) : 
LIC,CEB,| RQD1,FMH-7(0864¢)_ . MUC FMH—-7 , DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL 
(3) 0 SS ee ee Se = = >o 
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| FREE_SESSION . DEALLOCATE_RCB - DEALLOCATE( LOCAL ) 
(4) < >Q <r a ae a 


- BRACKET_FREED | RCB_DEALLOCATED . RC= ° 
< 2 SS SSeS SS >o 


re) 
Co NOTE: TPN on right gets no indication that DEALLOCATE_ABEND occurred 
because everything (including FMHs) are discarded when in purge state. 


Figure 2-6¢. DEALLOCATE(TYPE=ABEND_PROG) Issued in SEND_STATE Crossing SEND_ERROR--Remote LU 
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PS RM HS (to partner LU) 


TP 

: in RCV state P ‘ 
-DEALLOCATE j ; . 
. (ABEND_PROG } : SEND_ERROR . : 
o--------- > 0 


: MU( data ,NOT_END_OF_DATA) . FIC,data 
See Oe eee 1) 
(purge data) 


‘ : —RSP( 0846 ) 


: MU( PREPARE_TO_RCV_FLUSH ) . LIC,RQE1,CD»no data 
$i 8 


MU( FMH-7 »DEALLOCATE_FLUSH ) - OIC,CEB,RQD1,FMH-7( 0864 ) 


| DEALLOCATE_RCB - FREE_SESSION . +RSP 
>< Oe Orr 5) 


=OK . RCB_DEALLOCATED | BRACKET_FREED . 
a Se ae, a Se <a ae o< >o 


Figure 2-65. DEALLOCATE(TYPE=ABEND_PROG) Issued in RCV_STATE, Between-Chain State--Local LU 
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* 


(to partner LU) HS RM PS TP 
FIC ,data , MU( data »NOT_END_OF_DATA) . SEND_DATA | ; 
OO ee oe o 
: : [ RC= ‘ 
3 : © ee ee eee >o 
—RSP (0846 ) - MU( RECEIVE_ERROR } i 
(2)0§$ —— 7? | 
LIC,RQE1,CD,no data : MU( PREPARE_TO_RCV_FLUSH) ; SEND_DATA 
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6 —§ ee ee ee >o 
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L RCB_ pees orn RC=0K : 
— —_ ae ae a ee oe Pre) 
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Figure 2-66. DEALLOCATE( TYPE=ABEND_PROG ) Issued in RCV_STATE, Between-Chain State--Remote LU 
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TP PS RM HS | (to partner LU) 
»~RECEIVE_AND_WAIT . ; : 
CS SS = = >o . . 
RC=OK ,WHAT_RECEIVED= ; : 
' DATA_INCOMPLETE MU( data »NOT_END_OF_DATA) . FIC,data 
oe— - ------ = 5 — S11) 
DEALLOCATE : ‘ . 
( ABEND_PROG) , SEND_ERROR . - . =RSP(0846) 
—-------- >. Or (2) 
3 : MU( PREPARE_TO_RCV_FLUSH ) . LIC,RQE1,CD,no data 


‘ SSS SS a 0 5) 


MU( FMH-7,DEALLOCATE_FLUSH)  . OIC,CEB,RQD1,FMH—-7( 0864) 


‘ | DEALLOCATE_RCB  . FREE_SESSION . +RSP 

‘ 2 eS 
- RC=OK . RCB_DEALLOCATED | BRACKET_FREED . 

oc ee Ke eK KK o< . : >o 


Figure 2-67. DEALLOCATE( TYPE=ABEND_PROG) Issued in RCV_STATE, In-Chain State--Local LU 
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q ‘ (to partner LU) HS RM PS TP 
oot 


FIC,data : MU( data ,NOT_END_OF_DATA) .  SEND_DATA : 
a. oO 
: : [ RC= : 
é ee el eee >O 
—RSP( 0846) : MU( RECEIVE_ERROR) ; 
0 
LIC,RQE1,CD,no data ; MU( PREPARE_TO_RCV_FLUSH ) i SEND_DATA 
(3) 0 <—_e OOO meee eK ee ee 


, , - RC=DEALLOCATE_ . 
OIC ,CEB,RQD1 , FMH7( 0864 ) ° MU( FMH-7 ,DEALLOCATE_FLUSH ) . ABEND_PROG . 


6 )—§ —$ A 7 - - - >0 


+RSP | : oe RCB ae een 
C5 eee - - - 


- BRACKET_ BRACKET_FREED | ° ° 
Oe e e 


Figure 2-68. DEALLOCATE(TYPE=ABEND_PROG) Issued in RCV_STATE, In-Chain State--Remote LU 
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TP PS RM 
SEND_DATA 
Oo -------- >o 
RC=OK 
Pe eee J | 
CONFIRM MU( data ,CONFIRM ) 
Or ~~ K- K- - - - - > 
RC=OK CONFIRMED 
OSnm~ ~ rer mr we o< 


Figure 2-69. CONFIRM (RQD2/3)--Local LU 
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— — oe eee >Oo 
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Figure 2-70. CONFIRM (RQD2/3)--Remote LU 
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TP | PS RM HS (to partner LU) 


; Lo 
- SEND_DATA : . . 
o-------- >0 : : 
. RC=0K | ; ; 
oS = SS SS = . . 
PREPARE_TO_RECEIVE. : : 
( TYPE=CONFIRM, ° . : 
LOCKS=LONG) MU( data »,PREPARE_TO_RCV_CONFIRM_LONG) . OIC,RQE2|3,CD,data 
-------- > > $1) 
RC=OK i CONFIRMED . FIC,data aa 
o- - - -e- -- -K- o< o< : (2) ( | 
RECEIVE_AND_WAIT . Ro 
ses, HisBie ast ume, Cena aa >o 


- RC=OK »WHAT_RECEIVED= 


. DATA_INCOMPLETE MU( data »,NOT_END_OF_DATA) 


Figure 2-71. CONFIRM (RQE213)--Local LU 
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mn 


& (to partner LU) HS RM PS TP 


: . - RECEIVE_AND_WAIT . 


‘ : Se me wee eK Ke o 
: : RC=OK ,WHAT_RECEIVED= 
OIC ,RQE2|3,CD,data . MU(data,PREPARE_TO_RCV_CONFIRM) DATA_COMPLETE 
(1) 0 - - - - eH ee >o 
: : . RECEIVE_AND_WAIT 
: : o<—- ------- 
‘ : RC=OK »,NHAT_RECEIVED= 
‘ : CONFIRM_SEND . 
: a dT ce a ae) 
; CONFIRMED . CONFIRMED | 
CL Eee ae ae ee ee me 
: : RC=OK " 
: eee ee ee >o 
ar FIC data : MU( data ,NOT_END_OF_DATA) . SEND_DATA | 
C (2) 0 <——— 0 
: P | : RC=O0K e 
Cg Ee ee >o 


Figure 2-72. CONFIRM (RQE2/3)~--Remote LU 
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TP PS | , RM HS (to partner LU) 


- SEND_DATA é ‘ ° 
SSS SS Se >o ° ° 
- RC=OK ‘ . 
eee Z . ) 
PREPARE_TO_RECEIVE F ° 
( TYPE=CONFIRM ‘ : ‘ 
LOCKS=LONG ) .MU( data »PREPARE_TO_RCV_CONFIRM_LONG). OIC ,RQE2|3,CD,data 


4 ° an ae Se 


‘ ‘ MU( RECEIVE ERROR } ‘ —RSP (0846 ) 

‘ a nes ( 2) 
- RC='derived ‘ . ‘ ° 

5 from FMH-7' . MU( FMH-7,data,NOT_END_OF_DATA) ‘ FIC ,FMH-7,data 

Oo<—- - —- -—----- - eee ct Cen nens  ( FZ) 


Figure 2-73. CONFIRM (RQE2/3), SEND_ERROR--Local LU 
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mney 


C, (to partner LU) HS RM PS TP 


: ; RECEIVE_AND_WAIT 
. . Of SS ae oO 
; . RC=OK »,WHAT_RECEIVED= 
OIC ,RQE2|3,CD,data . MU(data,PREPARE_TO_RCV_CONFIRM) . DATA_COMPLETE 
CL) 7 rr - - - - >o 
: ‘ . RECEIVE _AND_WAIT 
: . OSS = SS SS SS = 
: : RC=OK ,NHAT_RECEIVED= 
, : a CONFIRM_SEND 
: See —“‘“‘™*SC*C*C*C‘CR ES Se a Oe LE >O 
—RSP( 0846 ) ; SEND_ERROR : SEND_ERROR | 
C2 <9 ir- - HH He ee 
: ; [L. RC=O0K : 
: wine ne eam ae ae em mee >o 
7 FIC,FMH—7,data! . MU(FMH-7,data!,NOT_END_OF_DATA) . SEND_DATA | 
SSO ee 
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: wae ce ame ee ee meme >o 


Note: 
The data consists of optional log data from the SEND_ERROR verb and the TP 
data from the SEND_DATA verb or the data from the SEND_DATA verb alone. 


Figure 2-74. CONFIRM (RQE213), SEND_ERROR--Remote LU 
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o< —_ es ewe se ae ew ae ee COO eo eer CS 


Figure 2-75. CONFIRM (RQD213), SEND_ERROR--Local LU 
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Figure 2-76. CONFIRM (RQD213), SEND_ERROR--Remote LU 
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DEALLOCATE( CONFIRM) MU( data ,DEALLOCATE_CONFIRM) : 
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‘ . MUC RECEIVE ERROR) ‘ 

. RC='derived ‘ ‘ 


from FMH-7'° . MU( FMH-7,data,NOT_END_OF_DATA) . 


—_—_ es es aw es =p ase ams am, renee 


Figure 2-77. DEALLOCATE(TYPE=CONFIRM), SEND_ERROR--Local LU 
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Figure 2-78. DEALLOCATE(TYPE=CONFIRM), SEND_ERROR--Remote LU 
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© SOE ee Oo 

EC,RQD2|3,CEB,data : MU( data ,DEALLOCATE_CONFIRM) : . 
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Figure 2-80. DEALLOCATE(TYPE=CONFIRM) Crossing SEND_ERROR--Remote LU 
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Figure 2-81. RECEIVE_AND_WAIT Causing RQE,CD--Local LU 
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Figure 2-82. RECEIVE_AND_WAIT Causing RQE,CD--Remote LU 
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Gre 
Figure 2-83. SEND_ERROR before SEND_DATA--Remote LU ( | 
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(> Figure 2-84. SEND_ERROR before SEND_DATA--Local LU 
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CHAPTER 3. LU RESOURCES MANAGER 
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GENERAL DESCRIPTION 


When one transaction program wishes to commu- 
nicate with another, the LU may activate, 
manage, and later deactivate a conversation. 
This chapter describes the management of con- 
“conversa- 


versation resources (or simply 


tions"). 


An LU contains a services manager, which in 
The 
resources manager stores information about 
active transaction programs, conversations, 
and LU-LU sessions in control blocks, some of 
which are the TCB, RCB, and SCB (see "Re- 


turn contains a resources manager, RM. 


RTR 


Initiator 


Session 
Manager 
(LU.SVC_MGR.SM) 


LU.SVC_MGR 


Buffer 
Manager 


Overview of Component Interactions Involving the Resources Manager 


sources Manager Data Base" on page 3-4 for 
additional information). 


The resources manager interacts with other 
components in the node. These components are 
shown in Figure 3-1. They are PS (“Chapter 
5.0. Overview of Presentation Services" and 
"Chapter 5.13 Presentation Serv- 
ices--Conversation Verbs"), SM ("Chapter 4. 
LU Session Manager"), HS (“Chapter 6.0. 
Half-Session"), BM (“Appendix B. Buffer Man- 
ager"), transaction-program-initiating proc- 
ess and Ready-to-Receive initiating process. 
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RESOURCES MANAGER FUNCTIONS 


The resources manager (RM) coordinates the 
following functions: 


® Creating new instances, and destroying 
existing instances, of presentation serv- 
ices 


e Attaching new instances, and destroying 
existing instances, of transaction pro- 
grams 


® Activating and deactivating conversations 


e Choosing sessions to be used by a conver- 
sation and, if necessary, requesting 
(bidding for) use of the session 


e Requesting the session manager (SM) to 
activate a new session or to deactivate 
an existing session 


e Coordinating normal cessation of conver- 
sation assignments to a particular ses- 


LU COMPONENT INTERACTIONS 


Other components in the LU with which the 
resources manager interacts are the presenta- 
tion services (PS) component associated with 
each transaction program instance attached to 
the LU, each half-session (HS) that is avail- 
able for use by the resources manager, and 
the session manager (SM). Examples of the 
type of interactions that take place are giv- 
en below. 


When presentation services is requested by 
its transaction program (TP) to initiate a 
conversation with another TP, it requests the 
resources manager to assist in the request. 
The resources manager is responsible for such 
tasks as choosing a session on which to ini- 
tiate the conversation; checking that the 
synchronization level and security level on 
the request correspond to what the target LU 
supports for this LU; and performing other 
functions necessary for acquiring a session 
for use by the requested conversation, such 
as creating the appropriate control blocks 
(see "Resources Manager Data Base" on page 
3-4 for more on control blocks). After the 
resources manager has completed processing of 
the request that it received from presenta- 
tion services, it sends a reply to PS inform- 
ing it of the outcome of the request. 


One type of unsolicited information that the 


resources manager sends to presentation serv- 


ices is an Attach FM header (FMH-5). When 
the resources manager receives an Attach from 
a remote LU via one of its half-sessions, it 
checks certain fields, including all security 
fields, carried in the Attach. Depending 
upon the installation-defined limit on the 
number of TP instances for the target trans- 
action program (instance limit, see TRANS- 


Peer Protocols 


sion targeted for deactivation (using 
BRACKET INITIATION STOPPED--BIS_ proto- 
cols) : 

(FMH-12 


¢ §©6©Completing LU-LU verification 


processing) 


e Replying to requests (bids) for use of a 
session that are received from remote 
resources managers 


¢ Providing services for support of the 
sync point log (the content and use of 
which is described in "Chapter 5.3. Pres- 
entation Services--Sync Point Services 
Verbs" )--these services are not formally 
defined in this book 

® Coordinating and managing 

conversation-level security 


ACTION_PROGRAM on page A-5), RM does one of 
two things: If the number of instances of 
the target transaction program has not yet 
reached its limit, RM creates a new instance 
of presentation services and sends’ the 
Attach, along with other information, to the 
new PS (“Attaching a Transaction Program" on 
page 3-10 and "Creation and Termination of 
Presentation Services" on page 3-18 provide 
additional details). If the instance limit 
has been reached, RM queues the Attach 
request. The Attach remains queued until a 
target TP-PS instance sends RM notification, 
Via a TERMINATE_PS record, of its readiness 
to accept another Attach request (or, if none 
1s queued, to be destroyed). 


Data that the resources manager wishes to 
send to another resources manager in the net- 
work is first sent to the local HS component 
of one of the sessions connecting the two 
LUs. Likewise, the resources manager 
receives from HS all data destined for the 
resources manager that comes in over a ses- 
sion. Examples of the Kind of data that 
flows between the resources manager and HS 
are bids for the use of a session, replies to 
bid requests, and Attach FM headers. 


When the resources manager receives a request 
from presentation services for a session and 
finds that no free sessions have the required 
characteristics, the resources manager sends 
a request to SM asking it to activate a new 
session. Similarly, the resources manager 
sends to the session manager a request that a 
session be deactivated upon notification by 
PC.COPR ("Chapter 5.¢. Presentation Serv- 
ices--Control-Operator Verbs") that too many 
sessions are active. SM replies to the 


CO 


resources manager after it has carried out 
the requested function. See “Activating a 
New Session" on page 3-15 and "Changing the 
Maximum Session Limit" on page 3-16 for more 
details on session activation and deacti- 
vation. 


Other components in the node, outside of the 
LU, with which the resources manager inter- 
acts are the buffer manager, local-TP initi- 
ator, and RTR initiator. 


The primary objective of node buffer manage- 
ment is to provide storage, allocation, and 
management for session-level pacing and to 
avoid unnecessary data movement from one 
buffer to another. 


For most of its work, RM uses transient stor- 
age, not managed by the node buffer manager ;» 


Resources 
Manager 


MU( FMH—5 ) 


aaa ea eae gd © 


(Format or protocol 
error detected) 


that is used for records that are local to 
the node and not sent outside the node. This 
transient storage is short-lived storage that 
is implicitly allocated by the creation of 
local records and freed when the records are 
destroyed. Node buffer management does not 
manage such transient storage. 


Incoming message units that may be queued for 
extended periods of time before being proc- 
essed use storage managed by the buffer man- 
ager. FMH-5 records may be queued for an 
instance-limited TP for an indefinite period 
of time. (For more information on 
instance-limited TPs refer to “Attaching a 
Transaction Program" on page 3-10.) FMH-7 
records may be queued for a TP that is not 
receiving. Storage for FMH records is man- 
aged by the buffer manager. 


Buffer 
Manager 


FREE_BUFFER(MU( FMH—5 ) ) 


Figure 3-2. Buffer Management for FMH-5 MU 
Resources 
HS Manager 
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a em earn 


Figure 3-3. 
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Buffer Management for FMH-12 MU 


When RM receives an FMH-5 record, it is con- 
tained in an MU. Normally, RM sends the 
FMH-5 MU to PS for further processing, but if 
RM detects a format or protocol error in the 
FMH-5 record, it discards the record by spec- 
ifying the FMH-5S MU in a FREE_BUFFER call to 
the buffer manager (see Figure 3-2). The 
FREE_BUFFER call informs the buffer manager 
that the storage for the discarded FMH MU is 
available. In the same way, when RM finishes 
processing FMH-12 MUs, it informs the buffer 
manager using FREE_BUFFER (see Figure 3-3). 


Certain independent processes, called initi- 
ating processes, interact with RM for the 
purpose of starting an initial transaction 
program, i.e., the originator of a distrib- 
uted transaction, or sending an RTR request 
to a partner LU, which allows the partner LU 
to initiate a conversation via a bid. These 
initiating processes include examples such as 
an application, a combined TP-PS process, a 
control-point process, the node operator 
facility (NOF), and RM itself. An initiating 
process is normally a privileged process. 
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RESOURCES MANAGER DATA BASE 


The resources manager needs information about 
such things as the transaction programs cur- 
rently attached to the LU, the conversations 
associated with each transaction program, and 
the sessions available for use by a conversa- 
tion between transaction programs. This 
information is stored in a group of control 
blocks found in the LU (see “Appendix A. Node 
Data Structures" for the control block defi- 
nitions). The resources manager initializes 
entries in some control blocks, while it only 
accesses or updates information -in entries 
already existing in other control blocks. 


CONTROL BLOCKS MAINTAINED BY THE RESOURCES 
MANAGER 


Information about transaction programs is 
contained in the transaction control block 
(TCB). One TCB exists for each active TP-PS 
process associated with the LU. Each TCB 
contains a TCB identifier (TCB_ID), which 
uniquely identifies the transaction program 
being represented by the TCB. The TCB_ID is 
also used in all communication between the 
resources manager and presentation services 
servicing the transaction program. For exam- 
ple, when presentation services sends a 
record to the resources manager, it provides 
its TCB_ID so that the resources manager will 
Know, of all the TP-PS processes it manages, 
which presentation services to send a reply 
to. Presentation services is informed of its 
TCB_ID when the TP-PS process is created by 
the resources manager. When the resources 
manager receives an’ Attach header (FMH-5) 
from a remote resources manager, it creates a 
new TCB, creates a new instance of presenta- 
tion services to be associated with the 
transaction program being attached, and sends 
the TCB_ID of the new TCB to presentation 
services. Thus, attaching a transaction pro- 
gram results in creation of a new TP-PS proc- 


ess for that transaction program, with which 
a presentation services component is always 
associated. 


Associated with each TCB is a group of 
resource control blocks (RCBs). One RCB 
exists in the group for each conversation 
associated with the transaction program. 
Besides the RCB_ID, an RCB contains several 
other pieces of information, such as_ the 
TCB_ID of the TP-PS process that is using the 
conversation; the LU name, mode name, and 
half-session identifier (HS_ID) of the ses- 
sion on which a conversation is running; and 
a field in which presentation services stores 
data that it receives from the transaction 
program. 


The final control block maintained by the 
resources manager is the session. control 
block (SCB). One SCB exists for each active 
session between the LU and a partner LU. 
Information contained in an SCB includes a 
half-session identifier (HS_ID) and the part- 
ner LU name (LU_NAME) and =*mode name 
(MODE_NAME) for the session. 


CONTROL BLOCKS ACCESSED BY THE RESOURCES MAN- 


AGER 


In addition to those control blocks managed 
by the resources manager, other’ control 
blocks exist that are managed by another com- 
ponent but are accessed and updated by the 
resources manager. 


One of these control blocks is MODE. There 
1s one MODE control block for each mode name 
that is defined for the particular LU. The 
MODE entry contains information that is fixed 
on a mode name basis such as session counts 
and session limits. 
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When the resources manager receives a message 
unit (MU) containing an Attach from HS for a 
TP that has not reached its instance limit, 
it creates a new TCB (representing the new 
instance of a TP-PS process) and RCB (repres- 
enting the transaction program's initial con- 
versation). It passes the IDs of the control 
blocks to the newly-created presentation 
services process (see “Attaching a Trans- 
action Program" on page 3-10). Once the 
transaction program is attached, it can ini- 
tiate conversations with other transaction 
programs. 


A TP-PS process can also be created as the 
result of a local request generated by a 
independent, initiating process running on 
the same system as RM. To start a trans- 
action program locally, the initiating proc- 
ess creates a START_TP record (refer to page 
A-19). The START_TP record contains informa- 
tion such as the name of the TP to be 
started; security tokens, e.g., user ID, 
password, and profile; and, if a reply to the 
START_TP request is desired, the identifica- 
tion of the initiating process. The START_TP 
record is sent to RM via a queue also used to 
receive SEND_RTR- records. RM treats a 
START_TP much like an Attach (1.e., it cre- 
ates the PS process and sends it the START_TP 
record), except that no conversation or RCB 
is associated with the request, and a reply 
(see START_TP_REPLY on page A-20) is 
optionally permitted. 


ALLOCATING A NEW CONVERSATION 


When the transaction program is ready to 
start a new conversation, 1%t issues an ALLO- 
CATE verb to presentation services. In gen- 
eral, presentation services separates the 
ALLOCATE request into two distinct functions, 
1.e., allocating an RCB and obtaining a ses- 
sion. Presentation services requests’ the 
resources manager to create a new RCB via an 
ALLOCATE_RCB record. The ALLOCATE_RCB con- 
tains information about the type of session 
that will be needed for the conversation. RM 
stores the session-related information in the 
new RCB and sends presentation services an 
RCB_ALLOCATED record, which contains the ID 
of the RCB. See Figure 3-4 for the flows 
that take place. 


OBTAINING A SESSION 


Once presentation services (PS) is informed 
of the ID of the new RCB, it requests that an 
LU-LU session be allocated to the conversa- 
tion. After RM has allocated an LU-LU ses- 
sion to satisfy the request from PS, PS 
creates an Attach FM header (FMH-5) (in a 
buffer obtained from the buffer manager) and 
places its address in the RCB. PS then 
returns to the transaction program. (see 
"Chapter 5.1. Presentation Serv- 


1ices-~Conversation Verbs" for specific 
details). 


Presentation services asks for a session to 
be allocated by sending a GET_SESSION record 
to the resources manager. The GET_SESSION 
contains the RCB_ID of the conversation that 
is to use the session. 


An LU attempts to allocate a session that it 
considers available. A session that is 
available is between brackets, is not cur- 
rently in conversation, and is not in the 
process of being terminated. A session that 
is available is referred to as being free. 
The set of free sessions at an LU is referred 
to as the free-session pool. The LU removes 
free sessions from the free-session pool when 
they are needed for conversations and returns 
them to the free-session pool when they are 
available. 


The resources manager at either end of a ses- 
sion connecting two LUs may attempt to allo- 
cate that session to a conversation. If both 
resources managers attempt to allocate the 
same session at the same time, there must be 
some way to resolve the contention for the 
session. For this reason, one of the LUs is 
designated the "first speaker" (or "“con- 
tention winner") and the other LU is desig- 
nated the “bidder” (or “contention loser" } 
for the session. The assignment of 
first-speaker and bidder status is estab- 
lished during session activation and remains 
in effect for the duration of the session. 
If more than one session exists between a 
pair of LUs, one LU may be the first speaker 
for some sessions and the bidder for the oth- 
ers. If an LU is the first speaker for a 
particular session, that session is said to 
be a first-speaker session for the LU. 


The resources manager in a bidder LU must 
request the resources manager in_- the 
first-speaker LU for permission to use a ses- 
sion. This is called "bidding" for a ses- 
sion. The first-speaker LU may either grant 
or deny the request for the session from the 
bidder LU by sending a positive or negative 
bid response. 


There are two forms of negative bid response 
associated with a parallel session. They are 
distinguished by the sense code in the nega- 
tive bid response. The first form (sense 
code X'0813') is the rejection of a bid with 
no restriction on bidding for the same ses- 
sion again. The second form (sense code 
X'081¢') is the rejection of a bid with the 
restriction that no further bids on the ses- 
sion are permitted until the first-speaker LU 
sends a Ready-to-Receive (RTR) record. This 
second form of bid rejection reserves the 
session for the first-speaker LU's use until 
it is ready to receive bids again for the 
session. The first-speaker LU may send RTR 
on the reserved session whenever the session 
is between brackets. When the RTR is sent is 
implementation or installation defined. This 
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Figure 3-5. 


3-6 


book models an initiator interface to RM that 
may be used to prompt RM to send the RTR. 
This prompt is modeled as a SEND_RTR record 


that is created and sent to RM by an RTR ini- 
tiating process. 


When a bid is rejected, the bidding LU may 
try to bid on the same session (depending 
upon the sense code in the negative bid 
response) or another session that is between 


Resources 
Manager 


Presentation 
Services 


- GET_SESSION(RCB_ID) . 
er 


brackets; if no sessions are between brack- 
ets, RM will queue the session allocation 
request to await the freeing of a session. 


If the resources manager in a first-speaker 
LU wishes to allocate a free session to a 
conversation, it may do so immediately, with- 
out requesting permission from the resources 
manager in the other LU. 


PS CONNECTED 


oO 


BID_WITHOUT_ATTACH 
————_——ooooeoee OO 


HS_ 
First- 
Speaker : 
Flows SESSION_ALLOCATED . 
o<——— 
-OR- 
Bidder : . 
Flows 


o< 


+BID_RSP 


HS_PS_CONNECTED 
oo 0 


SESSION_ALLOCATED . 
So 


The resources manager will always allocate a 
first-speaker session in preference to a bid- 
der session, to avoid the bidding procedure. 
Figure 3-5 illustrates the flows that take 
place when the resources manager attempts to 
allocate a session. The records used in the 
figure are defined in "Appendix A. Node Data 
Structures" in more detail. The following 


description refers to the numbers in the fig- | 


ure. 


1. Presentation services sends a GET_SESSION 
record to the resources manager. The 
RCB_ID identifies an RCB that was previ- 
ously allocated by the resources manager. 


2. If no first-speaker session is available, 
the resources manager must bid for use of 
a session. It sends BID_WITHOUT_ATTACH 
to the half-session. The bid will flow 
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Allocation of a Session Using BID_WITHOUT_ATTACH 


on the session to the resources manager 
at the partner LU. Between the time that 
the bid is sent and the bid response is 
received, the resources manager retains 
enough information to be able to proceed 
with session allocation when the bid 
response arrives. This information 
includes saving the HS_ID of the session 
and the GET_SESSION record in the RCB. 


3. The BID_RSP arrives from the remote 
resources manager via the half-session. 
The positive response indicates that the 
bid for use of the session has been 
accepted and the resources manager can 
complete the session allocation. Not 
shown in this figure is the processing of 
a -BID_RSP. In this case, the resources 
manager would attempt allocation of a 
different session, if possible. 


G. An HS_PS_CONNECTED record is sent by RM 5. A SESSION_ALLOCATED record is sent by RM 


ree to the half-session to inform the to presentation services to inform it 

C | half_session that it has been connected that a session has been allocated to the 

4 to a TP-PS process. conversation, satisfying the GET_SESSION 
request. 


=, 
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igure 3-6. Responding to a Bid for a Session 


Figure 3-6 illustrates the flows that take essing continues with receipt of the _ 
place when a Bid request is received by the Attach FM header from the half-session/ 
resources manager. The records used in the (3 and 4). : 
figure are defined in “Appendix A. Node Data 
Structures" in more detail. The following 2b. If RM responds with a -BID_RSP, the 
description refers to the numbers in the fig- request by the remote resources manager 
ure. to use the session is rejected. 
Lis A BID record is_ received from the + A message unit (MU) that includes 

half-session. The half-session sends a FMH-5( Attach) 1s sent from the 

BID record to RM whenever the partner LU half-session to RM. 

sends BB, regardless of whether’ the 

partner LU is bidder or first speaker. 4. RM creates a new TP-PS and sends the MU 

to PS. See "Attaching a Transaction »-—~ 

Za. If RM responds with a +BID_RSP, the Program" on page 3-10 for further ( 

request by the remote resources manager details. or 


to use the session is accepted and proc- 
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ALLOCATE_RCB ‘ : 
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First-Speaker ‘ oO 
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Figure 3-7. Immediate Allocation of a Session 


IMMEDIATE SESSION PROCESSING 


~\ Presentation services can request the 
) resources manager to allocate both an RCB and 
| a session with one record. ALLO- 


CATE_RCB( IMMEDIATE_SESSION=YES) embodies the 
function of both ALLOCATE_RCB and GET_SESSION 
in that when the processing completes suc- 


0 


cessfully, both an RCB and an SCB are allo- 
cated. ALLOCATE_RCB( IMMEDIATE_SESSION=YES ) 
instructs the resources manager to allocate 
an RCB only if a first-speaker half-session 
1s currently available. If such a 
half-session is not available, no allocation 
is performed. See Figure 3-7 for the specif- 
ic steps involved. 
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ATTACHING A TRANSACTION PROGRAM 
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One transaction program requests via an 
Attach FM header (FMH-5) that another trans- 
action program be attached to a conversation. 
The resources manager handles the receipt of 
the message unit (MU) that contains the 
Attach. Only one Attach is sent per conver- 
sation. RM processes the Attach and later 
sends it to PS_INITIALIZE in the TP-PS proc- 
ess for further processing. 


RM is responsible for checking certain fields 
of the Attach, such as the transaction pro- 
gram name field. RM performs all security 
checks of the Attach. (PS_INITIALIZE later 
checks the remaining fields). It notifies 
presentation services of the result of the 
checking through a field in the MU that RM 
sends to PS. 


If the Attach violates established protocol 
(e.g.» by sending an Already Verified indi- 
cation to a partner LU that does not accept 
it, by sending multiple passwords on a single 
Attach, or by indicating a synchronization 
level of syncpoint when the level for the 
session is confirm-only), RM instructs SM to 
generate and return an UNBIND and RM does not 
create a new instance of the TP-PS process. 
For all other errors found in the Attach 
(e.g.» invalid user ID, invalid parameter 
length), PS is responsible for returning an 
FMH-7 or for instructing SM, via RM, to 
return an UNBIND. These actions notify the 
transaction program that initiated the Attach 
of the error. 


If, after checking the Attach, no protocol 


error is found and the requested TP's 
instance count (number of TP-PS instances) is 
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less than its instance limit (as defined in 
the TRANSACTION_PROGRAM control block), the 
resources manager creates a new instance of 
the TP-PS process; it creates a new TCB and 
RCB; and it connects the TP-PS process to the 
half-session. RM notifies the half-session, 
via an HS_PS_ CONNECTED record, that it has 
been connected to a TP-PS process. Finally, 
RM sends the MU containing the Attach to the 
new instance of the TP-PS process. The MU 
contains the Attach FM header, the FMH-7 
sense data field (if applicable), and the IDs 
of the new TCB and RCB. Figure 3-8 depicts 
the steps -involved in Attach processing. 


If, after checking the Attach, no protocol 
error is found and the TP's instance count 
equals or exceeds the TP's instance limit, 
the resources manager creates a new RCB, con- 
nects the RCB with the half-session, informs 
the half-session of the RCB connection, and 
queues the MU containing the Attach to await 
an instance of the requested TP to become 
free. 


TP instances are free when all processing and 
conversations have been completed and the TP 
and its associated PS are ready to accept a 
new Attach or, if no Attach is queued for 
this TP, are ready to be destroyed. PS 
informs RM that it is free via the TERMI- 
NATE_PS record. 


Upon receipt of the TERMINATE_PS record, RM 
checks for a request queued for the trans- 
action program. If it finds a queued 
request, RM updates the associated TCB and 
sends the request to the TP-PS instance; oth- 
erwise, RM destroys the TP-PS process. 
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Figure 3-9. 
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Bid Races 


It is possible for the resources manager on 
each end of a session to simultaneously 
choose that session to service separate 
GET_SESSION records, causing a bid race. The 
resources manager on the first-speaker side 
of the session always wins such a bid race. 
When it receives the bid from the bidder RM, 
it recognizes that the session is already in 
use and generates a negative RSP(BID). When 
the bidder RM receives the negative RSP(BID), 
it checks the free-session pool to see if 
another session is available and retries the 
GET_SESSION processing on that session. Fig- 
ure 3-9 illustrates an example of a bid race 
and shows the RCB and SCB settings that allow 
a race condition to be detected. 


The negative RSP(BID) that is generated for a 
bid rejection can have a sense code of either 


RCB1.HS_ID = NULL 
STATE( FSM_RCB1_STATUS) = FREE 
Retry on another session 


0813 (Bracket Bid Reject—No RTR Forthcoming) 
or 0814 (Bracket Bid Reject—RTR Forthcom- 
ing). Either -RSP(BID,0813 ) or 
-RSP(BID,0814) may be sent, the decision 
being an implementation-dependent choice. 


An implementation may permit a transaction 
program to reserve a session before a conver- 
sation is started on that session. A bid for 
a reserved session is always rejected with a 
-RSP(BID,0814), since the transaction program 
might never begin a conversation on the 
reserved session (if, for example, the trans- 
action program terminated abnormally). The 
resources manager, by sending ane RTR; 
informs the partner LU that it can bid on the 
session again. 
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+RSPCRTR) 
Bid 
-OR- 
-RSP(RTR;, 0819) 
3-10. READY TO RECEIVE (RTR) Flow 


Figure 3-10 depicts possible RTR flows. In 
the situation where there is a bid race and 
-RSP(BID,0814) is sent, the resources manager 
at the bidder side of the session cannot bid 
again for that session until 1t has received 
an RTR_ from the’ first-speaker RM. Upon 
receipt of a -RSP(BID,0814), the bidder 
resources manager updates a field in the SCB 
to remember that -RSP(BID,0814) was received 
and retries the Bid on another session. From 
this point until the RTR is received, whenev- 
er a_conversation ends and the session 
becomes free, the session is not returned to 
the free session pool (fas is the normal 
case), thereby preventing the session from 
being chosen for bidding. 


When the current conversation ends, the 
first-speaker RM returns the session to the 
free-session pool and checks to see if any 
waiting requests can be satisfied by that 
session. The resources manager may use the 
session to service multiple GET_SESSION 
requests before sending the promised RTR. 


At some imp lementation-def ined or 
installation-controlled point, the resources 


Peer Protocols 


manager at the first-speaker side sends an 
RTR to the resources manager at the bidder /” 
side. This is a notification to the bidder' 
RM that 1t can now use the session. When the 
first-speaker RM sends the RTR, it removes 
the session from the free session pool to 
prevent that session from being chosen to 
service a request before the bidder RM has 
had a chance to respond to the RTR. 


When the bidder RM receives the RTR, 1t 
places the session in the free session pool 
(for the first time since receiving the 
-RSP(BID,0814) to the Bid). It then checks 
to see if a GET_SESSION record is waiting to 
be serviced, if so RM then sends a +RSP(RTR) 
(indicating that it intends to use the ses- 


sion) and ae Bid to the’ first-speaker 
resources manager. If no GET_SESSION records 
are waiting» the bidder sends a 
-RSP(RTR,0819). This indicates to the 


first-speaker RM that the bidder does not 
need the session. At this 
first-speaker places the session back intc 


the free session pool and checks for any\__ 


waiting requests. 


time,» the -—~ 
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Note: DEALLOCATE_RCB and FREE SESSION are independent records and can be sent to the resources 


manager in any order. 


Figure 3-11. End of a Conversation 


C) TERMINATING A CONVERSATION 


After the resources manager has established a 
conversation between two transaction pro- 
grams, it is not called upon to do any other 
processing for that conversation until the 
transaction programs are ready to end the 
conversation (see Figure 3-11). The 
resources manager is informed of the end of 
the conversation via two independent records. 


One record is DEALLOCATE_RCB, sent from pres- 
entation services. The other 1s 
FREE_SESSION, sent from HS to inform the 
resources manager that the session is now 
available for use by another conversation. 
Whichever record is received first triggers 
the resources manager to disconnect PS and 
HS. 
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Figure 3-12. Activation of a Session 
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ACTIVATING A NEW SESSION 
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The resources manager allocates sessions to 
be used by conversations. Presentation serv- 
ices requests the session be allocated with a 
GET_SESSION record. RM chooses sessions from 
the free session pool to satisfy the 
GET_SESSION request. If the pool is empty 
and the session limits allow the activation 
of a new session, the resources manager sends 
an ACTIVATE_SESSION record, containing the LU 
name and mode name of the desired session, to 
the session manager (SM, "Chapter 4. LU Ses- 
sion Manager"). Figure 3-12 on page 3-14 
illustrates the steps involved in activating 
a session. 


Although RM will not request session acti- 
vation if it would cause the session limits 
to be exceeded, SM is ultimately responsible 
for checking to see that the number of active 
sessions is not greater than the maximum num- 
ber of sessions allowed for that (LU name, 
mode name) pair. Some conditions (e.g.> a 
BIND race) will cause RM to request a session 
activation that would exceed the session lim- 
its. In this case, the activation request 
from RM is rejected with a negative ACTI- 
VATE_SESSION_RSP record. 


If the session can be activated, normal BIND 
protocols take place. When the session has 
been successfully activated, the SM component 
sends the resources manager a positive ACTI- 
VATE_SESSION_RSP record informing RM of the 
SCB_ID of the new session. 


In the following discussion, the numbers in 
parentheses correspond to the numbers in Fig- 
ure 3-12. 


When a new session is activated, RM sends an 
RM_HS_CONNECTED record to the new 
half-session. This record informs the new 
half-session that RM is aware of its exist- 
ence and is ready to accept records from it. 
A new session comes up in-bracket, with the 
resources manager on the primary side of the 
session having control of the session. This 


is true even if the resources manager on the 
secondary side of the session was the one 
that issued the ACTIVATE_SESSION record that 
caused the session to be activated (via INIT- 
SELF). Upon receipt of a positive ACTI- 
VATE_SESSION_RSP (or SESSION_ACTIVATED in the 
case of activation by the partner LU), RM 
creates and initializes an SCB based on the 
information carried in the ACTI- 
VATE_SESSION_RSP (or SESSION_ACTIVATED). 


If the newly activated session is a primary 
half-session, RM determines if any requests 
are waiting to be serviced. If LU-LU verifi- 
cation is not active and a request is waiting 
(1), RM uses the new session to service the 
request and sends a SESSION_ALLOCATED record 
to presentation services. If LU-LU verifica- 
tion is active and a request is waiting (2), 
RM will generate and send to the half-session 
an ENCIPHERED_RD2 record containing = § an 
FMH-12. Parameters within the ENCIPHERED_RD2 
record inform HS not to end the bracket nor 
to yield control of the session. RM then 
uses the new session to service the request 
and sends a SESSION_ALLOCATED record to pres- 
entation services. If no requests are wait- 
ing and LU-LU verification is active (3), RM 
will generate and send to the half-session an 
ENCIPHERED_RD2 record containing an FMH-12 
and parameters that inform the half-session 
to relinquish control of the session and to 
end the bracket. If no requests are waiting 
and LU-LU verification is not active (4), RM 
sends a YIELD_SESSION record to HS, thus 
yielding its right to use the session and 
ending the bracket. 


The resources manager at the partner LU (sec- 
ondary half-session) is notified of the ses- 
sion activation by a SESSION_ACTIVATED record 
from its SM component. If LU-LU verification 
is active, the secondary LU's resources man- 
ager will await receipt of a message unit 
(MU) that contains the FMH-12. When the MU 
is received and verified by the secondary LU, 
normal processing continues. 
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CHANGING THE MAXIMUM SESSION LIMIT 

The MODE control block (see page A-3) con- demand (explicit request). All such ses- i 

tains several session limit fields. These sions are first-speaker sessions. @ 

fields limit the number’ and polarity | ee 

(first-speaker or bidder) of sessions that an The change-number-of-sessions (CNOS) trans- 

LU can have with the partner LU and mode name action program ("Chapter 5.4¢. Presentation 

represented by the MODE control block. The Services--Control-Operator Verbs") can cause 

limit fields include: these session limits to change. The CNOS 
transaction programs at the two LUs come to 

® SESSION_LIMIT—maximum number of = ses- an agreement on what the new session limits 
sions. are to be via an exchange of Change Number of 

Sessions GDS variables (see SNA Formats). 

@ MIN_CONWINNERS_LIMIT—minimum number of After an agreement on the new session Limits 
potential first-speaker sessions, which is reached, each CNOS transaction program 
limits the maximum number of bidder ses- sends a CHANGE_SESSIONS record to its 
sions. The SESSION_LIMIT less the number resources manager. The CHANGE_SESSIONS noti- 
of bidder sessions must be greater than fies the resources manager that a change in 
or equal to MIN_CONWINNERS_LIMIT. the session limits has occurred. 

¢ MIN_CONLOSERS_LIMIT—minimum number of If the new session limits imply that new ses- 
potential bidder sessions, which limits silins may be activated, RM checks for any 
the maximum number of first-speaker ses- waiting session allocation requests. It cre- 
sions. The SESSION_LIMIT less the number ates multiple ACTIVATE_SESSION records, one 
of first-speaker sessions must be greater for each waiting request, and sends them i 
than or equal to MIN_CONLOSERS LIMIT. the session manager (see “Activating a New 

Session" on page 3-15 for more on session \ — A 

@ AUTO_ACTIVATIONS _LIMIT—the number of activation). The resources manager does not; 

session that are activated independent of however, request that more sessions be acti- 
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vated than can be accommodated by the new 
session limits. The excess requests are 
retained for later processing. 


The resources manager makes certain that at 
least the number of sessions equal to the 
AUTO_ACTIVATIONS LIMIT are active. After 
this number of sessions is active, RM 
requests session activation only to satisfy 
waiting requests. For example » if 
AUTO_ACTIVATIONS_LIMIT = 2 and five requests 
are waiting, but the new session limits imply 
that seven sessions could be concurrently 
active, the resources manager sends to the 
session manager only five ACTIVATE_SESSION 
records. 


When the session limits are decreased, one of 
the LUs 1s designated, by the 
CHANGE_SESSION_LIMIT verb's RESPONSIBLE 
parameter, as being "responsible" for deacti- 
vating sessions, as necessary to satisfy the 
new session limits. 
CHANGE_SESSION.RESPONSIBLE is set to YES if 


the resources manager is responsible to deac- 


tivate sessions. 


The resources manager computes in  TERMI- 
NATION_COUNT the number of sessions that its 
local LU is responsible to deactivate. RM 
chooses sessions to deactivate from the pool 
of free sessions with that LU and mode name, 
sending a BIS on each of the sessions that it 
has chosen and removing the entry for that 
session from the free session pool. The BIS 
is sent to inform the receiving resources 
manager that the sending RM will not initiate 
any subsequent brackets, and is sent only 
while the sending half-session is between 
brackets. When RM receives a BIS Reply 
(BIS REPLY on page A-12) in response to its 
BIS, 1t decrements the TERMINATION_COUNT and 
sends to the session manager a DEACTI- 


VATE_SESSION record for that session. The 
session manager then performs the normal 
UNBIND protocols. The exchange of BIS and 
its reply precedes a normal UNBIND (1i1.e., 
types X'O1l', X'02', or X'O3'). See Fig- 
ure 3-13 on page 3-16 for the steps involved. 


If not enough free sessions can be deacti- 
vated to bring the TERMINATION_COUNT to 0, RM 
waits for sessions that are currently in use 
to become free before it sends any more BISs. 


The value of the DRAIN_SELF field in the MODE 
control block determines whether RM will send 
BIS immediately when a session becomes free. 
If DRAIN_SELF = NO (1.e., waiting session 
allocation requests are not to be satisfied 
before session deactivation), RM will send 
BIS as soon as a session becomes free. If 
DRAIN_SELF = YES (1.e.» waiting session allo- 
cation requests are to be satisfied before 
session activation), RM will send BIS only if 
no waiting requests can be satisfied by the 
free session. In the same way, DRAIN_SELF 
determines when BIS Reply is sent in reply to 
a BIS’ from the partner LU; i1.e., if 
DRAIN_SELF = NO and the session is free, BIS 
Reply is sent immediately; otherwise, BIS 
Reply is sent only when no waiting requests 
can be satisfied by the session on which a 
BIS was received and the session is free. 

The LU control operator may also explicitly 
request that a session be activated or deac- 
tivated. RM is notified of these 
control-operator requests with an 
RM_ACTIVATE_SESSION or RM_DEACTIVATE_SESSION 
record. The resources manager is responsible 
for sending ACTIVATE_SESSION or  DEACTI- 
VATE_SESSION records (preceded by the usual 
exchange of BIS and its reply for normal 
deactivation) to the session manager to sat- 
isfy these control-operator requests. 
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SNA LU 6.2 Reference: 


An active session between two LUs sometimes 
fails. The session outage may be caused by a 
failure of one or both of the LUs, or by a 
failure in the path between the LUs. In the 
event of a session outage, the resources man- 
ager receives a SESSION_DEACTIVATED(REASON = 
SON) from the session manager. If the ses- 


AND TERMINATION OF PRESENTATION SERVICES 


The resources manager is responsible for cre- 
ating and terminating instances of presenta- 
tion services. (Presentation services, in 
turn, is responsible for starting up and tak- 
ing down the transaction program with which 
it is to be associated. ) 


Peer Protocols 


Network 
Services 


sion is 


entation services to inform it of the outage, 
and receives from PS a DEALLOCATE_RCB at some 
point. Regardless of whether the session is 
in use, RM destroys the associated SCB. Fig- 
ure 3-14 illustrates a session-outage flow. 


When a transaction program finishes its proc- 
essing, presentation services notifies the 
resources manager via a TERMINATE_PS record. 


C) 


See 


a 


being used by a conversation, RM/ ~ 
sends a CONVERSATION_FAILURE record to pres- | 


/ 


HIGH-LEVEL PROCEDURES 


Y 
RM 
FUNCTION: This process initializes the RM process giving RM addressability to pools 
(groups) of control blocks (e.g., LUCB, PARTNER_LU, MODE, TRANSACTION_PROGRAM; 
RCB, TCB, SCB), receives all input to the resources manager and routes the 
input to the appropriate procedure for processing. 
INPUT: A record is received asynchronously from session manager (SM), half-session 
(HS), presentation services (PS), and an initiator process. 
_ OUTPUT: Refer to the procedures that are called from this process for the outputs 
oo resulting from records received from other processes. 


NOTES: . An LUCB and TRANSACTION_PROGRAM (for initialization) are defined for this LU 
before RM is created. 


An initiator process may send records to RM when a_ transaction program is to 
be started locally or when READY-TO-RECEIVE is to be sent on a session. 


RM assumes that the LU, partner LUs, modes, and local transaction programs 
have been defined to the LU. RM also assumes that this definition is not 
changed by other components while RM is referencing the defined data. 


ae Throughout this description, RM sends records to other processes (e.g.,» HS,» 

* PS, SM). If the send of a record fails, the recovery action is to destroy the 

) record, log the failure in the system log, and continue processing. This send 
recovery action is not explicitly shown. 


Referenced procedures, FSMs, and data structures: 


PROCESS_SM_TO_RM_RECORD page 3-23 
PROCESS _HS_TO_RM_RECORD page 3-20 
PROCESS INITIATOR_TO_RM_RECORD page 3-20 
PROCESS_PS_TO_RM_RECORD page 3-22 
PREVIOUS_TIME page 3-92 
pO Initialize PREVIOUS TIME to the current system time (for more information refer to page 3-41) 
( Do forever: 
ee Receive a record. 
Select based on the sender of the record: 
When SM | 
Call PROCESS_SM_TO_RM_RECORD(record received) (page 3-23). 
When HS 


Call PROCESS_HS_TO_RM_RECORD(record received) (page 3-20). 
When INITIATOR 

Call PROCESS_INITIATOR_TO_RM_RECORD( record received) (page 3-20). 
When PS 

Call PROCESS_PS_TO_RM_RECORD(record received) (page 3-22). 
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PROCESS_INITIATOR_TO_RM_RECORD 


This procedure routes records received from an initiator process to the appro- 
priate procedures for processing. 


The current record from the initiator process 


Refer to the procedures that are called from this process for the specific 


outputs. 


Referenced procedures, FSMs, and data structures: 


SEND_RTR_PROC page 3-69 
START_TP_PROC page 3-77 
START_TP page A-19 
SEND_RTR page A-20 


Select based on the type of record received: 
When START_TP 
Call START_TP_PROC(START_TP) (page 3-77). 
When SEND_RTR 
Call SEND_RTR_PROC(SEND_RTR) (page 3-69). 


Otherwise 


Log the error to the system log. 
Destroy the record. 


PROCESS _HS_TO_RM_RECORD 


FUNCTION: 


INPUT : 


OUTPUT: 


NOTES: 


1. 


This procedure routes records received from HS to the appropriate procedures 


for processing. 
The current record from a half-session 


Refer to the procedures that are called from this process for the specific 


outputs. 


in the 
could occur, for example, 
before RM had processed all the records 


received 
if session 
from that 


If an SCB is not found with an HS_ID matching the HS_ID 


record, the record is discarded. This 
outage occurred 
half-session. 


If #FSM_BIS indicates that the session is closed, the record is discarded. 
This could occur, if the resources manager in the partner LU sends a -RSP(RTR) 
after having sent BIS_REPLY. 


Referenced procedures, FSMs, and data structures: 
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HS page 6.0-3 

BID_PROC page 3-33 

BID_RSP_PROC page 3-35 

ATTACH_PROC page 3-30 
FREE_SESSION_PROC page 3-50 

RTR_RQ_PROC page 3-63 

RTR_RSP_PROC page 3-64 

SECURITY_PROC page 3-65 
FSM_BIS_BIDDER page 3-87 

FSM_BIS_FSP page 3-88 

MU page A-29 

BID page A-1l 

BID_RSP page A-11l 

BIS_RQ page A-12 

BIS REPLY page A-12 i 
FREE SESSION page A-12 / 
RTR_RQ page A-12 

RTR_RSP page A-13 

SCB page A-& 


Peer Protocols 


PROCESS_HS_TO_RM_RECORD 


If the record is an MU then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the MU (Appendix B). 
Else 
Destroy the record. 
Log the error to the system log. 


C If no corresponding SCB is found for the HS process that sent the record then (Note 1) 
/ 


Else 
If the state of #FSM_BIS # CLOSED (page 3-87) then 
Select based on the type of record received: 
When BID 
Call BID_PROC(BID) (page 3-33). 
When BID_RSP 
Call BID_RSP_PROC(BID_RSP) (page 3-35). 
When MU 
If the MU contains an FMH-5 then 
Call ATTACH_PROC(MU) (page 3-30). 
If the MU contains an FMH-12 then 
Call SECURITY_PROC(MU) (page 3-65). 
When FREE_SESSION 
~. Call FREE_SESSION_PROC( FREE_SESSION) (page 3-50). 
S When RTR_RQ 
., Call RTR_RQ_PROC(RTR_RQ) (page 3-63). 
When RTR_RSP 
Call RTR_RSP_PROC(RTR_RSP) (page 3-64). 
When BIS_RQ 
Call #FSM_BIS(R, BIS_RQ, BIS_RQ.HS_ID) (page 3-87). 
associated with the half-session over which the BIS_RQ was received. 
(#FSM_BIS initialized in CREATE_SCB) 
When BIS_REPLY 
Call #FSM_BIS(R, BIS_REPLY, BIS_REPLY.HS_ID) (page 3-87) 
associated with the half-session over which the BIS_REPLY was received 
(#FSM_BIS initialized in CREATE_SCB). 
Else (Note 2) 


aoe If the record is an MU then 
= Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
; containing the MU (refer to Appendix B). 
Log the error to the system log. 
Else 
Destroy the record. 
Log the error to the system log. 
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PROCESS PS_TO_RM_RECORD 


FUNCTION: This procedure routes records received from presentation services to the 
appropriate procedures for processing. 


INPUT: The current record from presentation services 


OUTPUT: Refer to the procedures that are called from this procedure for the specific 
outputs. . 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
ALLOCATE_RCB_PROC page 3-26 
GET_SESSION_PROC page 3-52 
PS_TERMINATION_PROC page 3-57 
CHANGE_SESSIONS_PROC page 3-39 
RM_ACTIVATE_SESSION_PROC page 3-6l 
RM_DEACTIVATE_SESSION_PROC page 3-62 
SEND_DEACTIVATE_SESSION page 3-68 
PS_ABEND_PROC page 3-54 
RCB page A-6 
SCB page A-8 
ALLOCATE_RCB page A-15 
GET_SESSION page A-16 
DEALLOCATE_RCB page A-16 
RCB_DEALLOCATED page A-21 
BRACKET_FREED page A-18 
TERMINATE_PS page A-17 
CHANGE_SESSIONS page A-15 
RM_ACTIVATE_SESSION page A-16 
RM_DEACTIVATE_SESSION page A-17 
UNBIND_PROTOCOL_ERROR page A-17 
ABEND_NOTIFICATION page A-25 


Select based on type of record received: 
When ALLOCATE_RCB 
Call ALLOCATE_RCB_PROC( ALLOCATE_RCB) (page 3-26). 
When GET_SESSION 
Call GET_SESSION_PROC(GET_SESSION) (page 3-52). 
When DEALLOCATE_RCB 
Find the RCB with RCB_ID equal to DEALLOCATE_RCB.RCB_ID. 
If there is no SCB with RCB_ID equal to DEALLOCATE_RCB.RCB_ID then 
Create a BRACKET_FREED (page A-18) 
with BRACKET_ID set to RCB.BRACKET_ID. 
Send the record to HS (Chapter 6.0). 
Discard the RCB. 
Build an RCB_DEALLOCATED record and send it to PS. (Chapter 5.0). 
When TERMINATE_PS 
Call PS_TERMINATION_PROC( TERMINATE_PS). (page 3-57). 
When CHANGE_SESSIONS 
, Call CHANGE_SESSIONS PROC(CHANGE_SESSIONS). (page 3-39). 
When RM_ACTIVATE_SESSION 
Call RM_ACTIVATE_SESSION_PROC(RM_ACTIVATE_SESSION). (page 3-61). 
When RM_DEACTIVATE_SESSION 
Call RM_DEACTIVATE_SESSION_PROC(RM_DEACTIVATE_SESSION). (page 3-62). 
When UNBIND_PROTOCOL_ERROR 
Call SEND_DEACTIVATE_SESSION( ACTIVE ,UNBIND_PROTOCOL_ERROR.HS_ID,ABNORMAL 
UNBIND_PROTOCOL_ERROR.SENSE_CODE}. (page 3-68). 
When ABEND_NOTIFICATION 
Call PS_ABEND_PROC( ABEND_NOTIFICATION) (page 3-54). 
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PROCESS_SM_TO_RM_RECORD 
PROCESS _SM_TO_RM_RECORD 


Co 


FUNCTION: This procedure routes records received from SM to the appropriate procedures 
| for processing. 


INPUT: The current record from SM 


OUTPUT: Refer to the procedures that are called from this procedure for the specific 
outputs. 


Referenced procedures, FSMs, and data structures: 


ACTIVATE_SESSION_RSP_PROC page 3-25 
SESSION_ACTIVATED_PROC . page 3-70 
SESSION_DEACTIVATED_PROC page 3-72 
ACTIVATE_SESSION_RSP page A-13 
SESSION_ACTIVATED page A-14 
SESSION_DEACTIVATED page A-14 

~~ Select based on the type of record received: 

/ When ACTIVATE_SESSION_RSP 


Call ACTIVATE_SESSION_RSP_PROC( ACTIVATE_SESSION_RSP) (page 3-25). 
When SESSION_ACTIVATED 

Call SESSION_ACTIVATED_PROC(SESSION_ACTIVATED) (page 3-70). 
When SESSION_DEACTIVATED 

Call SESSION _DEACTIVATED_PROC(SESSION_DEACTIVATED) (page 3-72). 


& 
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ACTIVATE_NEEDED_SESSIONS 


FUNCTION: This procedure activates sessions as required by the number of waiting 
requests and change-number-of-sessions (CNOS) processing. 


Sessions are activated so as to satisfy the waiting requests, but not to 
exceed the (LU, mode) session limit. If all waiting requests are satisfied, 
additional sessions are activated to bring the number of sessions up to the 
minimum of the MODE .AUTO_ACTIVATIONS LIMIT and MODE .MIN_CONWINNERS LIMIT. 


~ INPUT: The LU name and mode name, respectively, of the partner LU 


OUTPUT : Zero or more ACTIVATE_SESSION records to SM 


Referenced procedures, FSMs, and data structures: 


SM page 4-48 
SESSION_ACTIVATION_POLARITY page 3-71 
SEND_ACTIVATE_SESSION page 3-65 
LU_NAME page 3-91 
MODE_NAME page 3-91 
ACTIVATE_SESSION | page A-20 
MODE page A-3 


Get addressability to the MODE control block associated with LU_NAME and 
MODE_NAME . 
Do for each waiting request for sessions identified by LU_NAME and MODE_NAME 
while the polarity returned by SESSION_ACTIVATION_POLARTIY( LU_NAME »,MODE_NAME ) 
(page 3-71) # NONE. 
If polarity = FIRST_SPEAKER then 
Call SEND_ACTIVATE_SESSION( LU_NAME, MODE_NAME, FIRST_SPEAKER) (page 3-65) 
to send an ACTIVATE_SESSION record to SM. 
Else (BIDDER) 
Call SEND_ACTIVATE_SESSION( LU_NAME, MODE_NAME, BIDDER) (page 3-65). 
Do while (MODE .ACTIVE_CONWINNERS COUNT + MODE.PENDING_CONWINNERS COUNT) < 
the minimum of (MODE .AUTO_ACTIVATIONS_ LIMIT, MODE .MIN_CONWINNERS LIMIT) and the polarity 
returned by SESSION_ACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-71) = FIRST_SPEAKER. 
Call SEND_ACTIVATE_SESSION( LU_NAME, MODE_NAME, FIRST_SPEAKER) (page 3-65). 
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ACTIVATE_SESSION_RSP_PROC 


FUNCTION: This. procedure handles the processing of the response to a previously issued 
ACTIVATE_SESSION request. 


The session counts in the appropriate MODE entry are updated and further proc- 
essing is invoked depending on the response type. 


ACTIVATE_SESSION_RSP from SM 


SESSION_ALLOCATED to PS, the mode session counts are adjusted, and pending 
activate session requests are discarded 


The PENDING_ACTIVATION will not be found if RM had previously requested deac~ 
tivation of the pending session as a result of change-number-of-sessions proc- 
essing. In this case, no processing of the ACTIVATE_SESSION_RSP is performed, 
since the session is being deactivated. 


—, Referenced procedures, FSMs, and data structures: 
@ : SUCCESSFUL_SESSION_ACTIVATION page 3-80 
See UNSUCCESSFUL_SESSION_ACTIVATION page 3-83 
ACTIVATE_SESSION_RSP page A-13 
PENDING_ACTIVATION, see ACTIVATE_SESSION page A-20 
MODE page A-3 


If there exists a PENDING_ACTIVATION with a correlator equal to 
ACTIVATE_SESSION_RSP.CORRELATOR then 
Get addressability to the MODE control block associated with the LU_NAME and 
MODE_NAME of the PENDING _ACTIVATION. 
Decrement MODE.PENDING_CONWINNERS_ COUNT or MODE .PENDING_CONLOSERS_ COUNT by 1, 
as appropriate to the session polarity. 
Decrement MODE.PENDING_SESSION_COUNT by 1. 
aa If ACTIVATE_SESSION_RSP.TYPE = POS then 
C) Increment MODE .ACTIVE_CONWINNERS_COUNT or MODE.ACTIVE_CONLOSERS_COUNT by 1, 
as appropriate to the session polarity. 
Increment MODE .ACTIVE_SESSION_COUNT by 1. 
Call SUCCESSFUL_SESSION_ACTIVATION( PENDING_ACTIVATION.LU_NAME ; 
PENDING_ACTIVATION.MODE_NAME, ACTIVATE_SESSION_RSP.SESSION_INFORMATION) (page 3-80). 
Else (negative response) 
Call UNSUCCESSFUL_SESSION_ACTIVATION( PENDING_ACTIVATION.LU_NAME ; 
PENDING _ACTIVATION.MODE_NAME, ACTIVATE_SESSION_RSP.ERROR_TYPE) (page 3-83). 
Discard the PENDING_ACTIVATION 
Else 
Do nothing (see Note). 
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ALLOCATE_RCB_PROC 


FUNCTION: This procedure handles the allocation of resource control blocks (RCBs). 


This procedure creates the RCB_ALLOCATED record and initializes the fields of 
the record. It then calls the appropriate procedure, depending upon the ALLO- 
CATE_RCB parameter settings. The procedure that this procedure calls changes 
the setting of some of the RCB_ALLOCATED fields. The RCB_ALLOCATED is then 
sent to PS to inform it of the outcome of the ALLOCATE_RCB request. 


ALLOCATE_RCB 
RCB_ALLOCATED to PS 


When ALLOCATE_RCB.IMMEDIATE_SESSION is set to YES, RM is to check to see if a 
first-speaker half-session is currently available for use. If such a session 
is available, the RCB_ID is passed to PS and the request completes successful- 
ly. (If IMMEDIATE_SESSION is set to NO, PS sends a separate GET_SESSION 
request to RM to request that a half-session be allocated to a particular con- 
versation resource. ) 


Referenced procedures, FSMs», and data structures: 


TEST_FOR_FREE_FSP_SESSION page 3-82 
CREATE_RCB page 3-43 
PS page 5.0-8 
ALLOCATE_RCB page A-15 
RCB_ALLOCATED : page A-21l 


Create an RCB_ALLOCATED record initializing RETURN_CODE to OK and RCB_ID to a null value. 
If ALLOCATE_RCB.IMMEDIATE_SESSION is set to YES then 
Call TEST_FOR_FREE_FSP_SESSION( ALLOCATE_RCB, RCB_ALLOCATED) (page 3-82). 


Else 

Call CREATE_RCB(ALLOCATE_RCB, RCB_ALLOCATED) (page 3-43). as 
Send the RCB_ALLOCATED record to PS (Chapter 5.0). ( 
Destroy ALLOCATE_RCB. Nec 


ATTACH_CHECK 


FUNCTION: This procedure checks particular fields of the passed FM header 5 (FMH-5) for 
validity. (PS is responsible for additional checks. ) 


INPUT: An FM header 5 and the HS _ID of the half-session (See SNA Formats for the for- 
mats of FM headers) 


OUTPUT: X'00000000', 1f no error; or sense data returned by ATTACH_LENGTH_CHECK; or 
data returned by ATTACH_SECURITY_CHECKs;s or one of the following sense data 
values: 


X'O80F6051" Security Not Valid 

X'084B6031' ~ TP Not Available--Retry Allowed 
X'084C0000' TP Not Available--No Retry 
X'1008600B ' Unrecognized FMH Command 
X'10086011' Invalid Logical Unit of Work 
X'10086021' TP Name Not Recognized 

X' 10086040 ' Invalid Attach Parameter 
X'10086041' Sync Level Not Supported 


Referenced procedures, FSMs, and data structures: 


ATTACH_LENGTH_CHECK page 3-28 
ATTACH_SECURITY_CHECK page 3-32 
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Select based on the Command field of the FMH-5: 
When Attach (The FMH-5 is an Attach FM header ) 


ATTACH_CHECK 


Call ATTACH_LENGTH_CHECK( Attach) (page 3-28) to determine whether any 


FMH~-5 fields have an invalid length. 


If ATTACH_LENGTH_CHECK indicates that a field length is invalid then 
Return with the sense data provided by ATTACH_LENGTH_CHECK. 
If a logical-unit-of-work ID (LUW ID) is present in the Attach then 
If the logical-unit-of-work ID's network-qualified LU name has a null network ID and 
the receiving LU has a non-null network ID in its network-qualified LU name then 
Return with sense data X'10086011'. (A null network ID in LUW is not valid unless 
this LU's network ID is also null.) 


Else (LUW ID not present) 
If the sync level specified in the Attach is SYNCPT then 


Return with sense data X'10086011' (LUW required on sync point conversations). 
If the transaction program specified in the Attach exists at this LU then 


Select based on the sync level specified in the Attach: 


(Optional receive check--the sync level support specified 


in the FMH-5 must be compatible with the sync level 
supported by the partner LU). 
When None or Confirm 


Do nothing. (All LUs support sync level None and Confirm. ) 


When Confirm, Sync Point, and Backout 


If the sessions to the remote LU do not support confirm, sync point, 


and backout then 


Return with sense data X'10086040' (Invalid Attach Parameter ). 


Otherwise 


Return with sense data X‘'10086040' (Unrecognized sync level). 
If the sync level specified in the Attach is not supported by 


the transaction program then 


Return with sense data X'10086041' (Sync Level Not Supported). 


If the transaction program is temporarily disabled then 


Return with sense data X'084B6031' (TP Not Available--Retry Allowed). 


If the transaction program is permanently disabled then 


Return with sense data X'084C0000' (TP Not Available--No Retry). 


If the transaction program requires security parameters in the Attach and the 


sending LU is not permitted by this LU to send them (as communicated in Bind) then 
Return with sense data X'O80F6051' (Security Not Valid). 
Call ATTACH_SECURITY_CHECK( Attach) (page 3-32) to check that all security 


requirements are met. 


If ATTACH_SECURITY_CHECK indicates a security violation then 


Return with the data provided by ATTACH_SECURITY_CHECK. 
Else 


Return with sense data X'10086021' (TP Name Not Recognized). 


Otherwise 


Return with sense data X'1008600B' (Unrecognized FMH-5 command field). 


Return with sense data X'00000000' indicating no error. 
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ATTACH_LENGTH_CHECK 


FUNCTION: This procedure checks the length fields in the passed Attach for validity. 


INPUT: An FMH-5 Attach header (see SNA Formats ) 


OUTPUT: Sense data values reflecting the result of the length checks. One of the fol- 
lowing sense data values is returned: 


x"00000000' No error 

x°'10086000' FMH Length Not Correct 

X*'10086005 ' Access Security Information Length Invalid 
X*'10086009' Invalid Parameter Length 

X'10086011' Invalid Logical Unit of Work 


The total length of the Attach can be greater than the sum of the lengths of 
the currently defined fields, to allow for the addition of new Attach fields. 


Set BYTE_OFFSET to 5 (offset of Fixed Length Parameters field in Attach). 
If the Attach length ¢ BYTE_OFFSET then a 
Return with X'10086000' (FMH Length Not Correct). \ ; 
If the value of the Fixed Length Parameters field < 3 then li 
Return with X'10086009' (Invalid Parameter Length). 
Set BYTE_OFFSET to BYTE_OFFSET + the value of the Fixed Length Parameters field + 1 
(offset of TP name Length field). 
If the Attach length < BYTE_OFFSET then 
Return with X'10086000' (FMH Length Not Correct). | 
Set BYTE_OFFSET to BYTE_OFFSET + the value of the TP name Length field + 1 
(offset of Access Security Information Length field). 
Select based on the following comparisons: 
When the Attach length < BYTE_OFFSET 
Return with X'10086000' (FMH Length Not Correct). 
When the Attach length = BYTE_OFFSET 
Return with X'00000000' (Access Security Information and fields following not present). 
When the Attach length > BYTE_OFFSET (Access Security Information present) . 
Continue processing. 
If the value of the Access Security Information Length field > 0 then 
(Access Security information is present) 
If the Access Security subfield length > the allowed length (12) or 
more than three Access Security subfields are present or 
the sum of the lengths of the Access Security subfields does not equal 
the total length of the Access Security Information field then 
Return with X‘'10086005' (Access Security Information Length Invalid). 
Set BYTE_OFFSET to BYTE_OFFSET + the value of the Access Security Information Length field + 1 
(offset of LUW Identifier Length field). 
Select based on the following comparisons: pes 
When the Attach length < BYTE_OFFSET 
Return with X'10086000' (FMH Length Not Correct). 
When the Attach length = BYTE_OFFSET 
Return with X'00000000' (LUW Identifier and following fields not present). 
When the Attach length > BYTE_OFFSET (LUW Identifier present) 
Do nothing. 
If the value of the LUW Identifier Length field > 0 then (LUW Identifier present) 
If the value of the LUW Identifier Length field < 10 or > 26 then 
Return with X'10086011' (Invalid Logical Unit of Work). 
If the value of the LUW Identifier Length field * the value of the LUW Identifier 
LU name Length field + 9 then 
Return with X'10086011' (Invalid Logical Unit of Work). 
Set BYTE_OFFSET to BYTE_OFFSET + the value of the LUW Identifier Length field + 1 
(offset of Conversation Correlator Length field). 
Select based on the following comparisons: 
When the Attach length < BYTE_OFFSET 
Return with X'10086000' (FMH Length Not Correct). 
When the Attach length = BYTE_OFFSET 
Return with X'00000000' (Conversation Correlator not present). 
When the Attach length > BYTE_OFFSET (Conversation Correlator present) 
Do nothing. 


i 

‘ 
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ATTACH_LENGTH_CHECK 


Set BYTE_OFFSET to BYTE_OFFSET + the value of the Conversation Correlator Length field + 1 
(offset of byte following ATTACH). 
If the Attach length < BYTE_OFFSET then 
Return with X'10086000' (FMH Length Not Correct). 
Else 
Return with X'00000000' (All length fields in Attach are valid). 
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ATTACH_PROC 


FUNCTION: 


INPUT : 


OUTPUT : 


NOTES: 1. 


This procedure performs Attach processing. 


This procedure checks to see if the session is already in use. If the session 


is not in use, the appropriate subroutines are called to check certain fields 
in the Attach FM header for validity. If a partner-LU protocol error is 
found, the appropriate procedure is called to deactivate the session; other- 
wise, a new conversation with a new PS process is started. 


An MU containing an FM Header 5 

None 

If the state of #FSM_SCB_STATUS (initialized in CREATE_SCB ) is  PEND- 
ING_ATTACH, the half-session is first-speaker and a prior BID was received, or 


the half-session is a_ secondary first-speaker or bidder and has just been 
activated. 


This protocol error occurs, for example,» when the first-speaker half-session 
sends an Attach FM header after having positively responded to a Bid from the 
bidder half-session, or when an Attach FM header is received for which there 
was no prior Bid. 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-68 
ATTACH_CHECK page 3-26 
PS_CREATION_PROC page 3-55 
QUEUE_ATTACH_PROC page 3-60 
PURGE_QUEUED_ REQUESTS page 3-59 
SEND_ATTACH_TO_PS page 3-66 
FSM_SCB_STATUS_BIDDER : page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
CONNECT_RCB_AND_SCB page 3-42 
TRANSACTION_PROGRAM page A-5 
MU | page A-29 
TCB_ID page 3-91 
RCB_ID page 3-91 
SCB page A-8& 


Set TCB_ID and RCB_ID to null. 
Find the SCB corresponding to the HS process that sent the Attach. 
If the state of the #FSM_SCB_STATUS -= PENDING_ATTACH then (Note 2) 
Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL, X'20030000'). (page 3-68) 


Else 


Call ATTACH_CHECK( FMH_5, MU.HS_TO_RM.HS_ID) (page 3-26) to determine if the 
Attach contains any errors. 
Select based on the sense data returned by ATTACH_CHECK. 
When X'FFFFFFFF' 


Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL, X'O80F6051'). (page 3-68) 
Call buffer manager(FREE_BUFFER, buffer address) to release the buffer containing MU 
(Appendix B). 


When X'10086040 ' 


Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL, X'10086040'). (page 3-68) 
Call buffer manager(FREE_BUFFER, buffer address) to release the buffer containing MU 
(Appendix B). 


When X'10086011' 


Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL, X'10086011'). (page 3-68) 
Call buffer manager( FREE_BUFFER, buffer address) to release the buffer containing MU 
(Appendix B). 


Otherwise 
Select based on the FMH_5.COMMAND. 
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ATTACH_PROC 


When ATTACH 
If the sense data returned by ATTACH_CHECK -= X'10086021' then 
(TP name recognized) 

Find the TRANSACTION_PROGRAM structure corresponding to the 
transaction program named in the Attach record. 

If the sense data returned by ATTACH_CHECK ~= X‘'00000000' or 
TRANSACTION_PROGRAM. INSTANCE_COUNT < TRANSACTION_PROGRAM. INSTANCE_LIMIT 
then 

Call PS_CREATION_PROC(MU, TCB_ID, RCB_ID, TRANSACTION_PROGRAM,CREATE_RC). 
(page 3-55) 
If CREATE_RC is SUCCESS then 
Call #FSM_SCB_STATUS(R, ATTACH, UNDEFINED) (page 3-84). 
Set SCB.RCB_ID to RCB_ID. 
Call CONNECT_RCB_AND_SCB(RCB_ID, MU.HS_TO_RM.HS_ID). (page 3-42) 
Call SEND_ATTACH_TO_PS(MU, TCB_ID, RCB_ID» sense code). (page 3-66) 
Else (PS creation failed) 
If the TRANSACTION_PROGRAM.INSTANCE_COUNT is greater than 0 and 
the sense data returned by ATTACH_CHECK=X'00000000' then 
Call QUEUE_ATTACH_PROC(MU) (page 3-60). 
Else 
Call SEND_DEACTIVATE_SESSION( ACTIVE, MU.HS_TO_RM.HS_ID, ABNORMAL, 
x'08640000') (page 3-68). 
Call buffer manager(FREE_BUFFER, buffer address) to release the 
buffer containing MU (Appendix B). 
Log the creation failure in the system log. 
If the TRANSACTION _PROGRAM.INSTANCE_COUNT is 0 then 
Call PURGE_QUEUED_REQUESTS( TRANSACTION PROGRAM) (page 3-59). 
Else 
Call QUEUE_ATTACH_PROC(MU). (page 3-60) 
Else (TP name is not recognized) 
Set the pointer to the TRANSACTION_PROGRAM structure to null. 
Call PS CREATION PROC(MU, TCB_ID, RCB_ID» TRANSACTION PROGRAM, CREATE_RC). 
(page 3-55) (Create a PS to reject the Attach. ) 
If CREATE_RC is SUCCESS then 
Call #FSM_SCB_STATUS(R, ATTACH, UNDEFINED) (page 3-84). 
Set SCB.RCB_ID to RCB_ID. 
Call CONNECT_RCB_AND_SCB(RCB_ID, MU.HS_TO_RM.HS_ID). (page 3-42) 
Call SEND_ATTACH_TO_PS(MU, TCB_ID, RCB_ID, sense code). (page 3-66) 

Else (PS creation failed) 

Call SEND_DEACTIVATE_SESSION( ACTIVE, MU.HS_TO_RM.HS_ID, ABNORMAL, 
X'08640000') (page 3-68). 

Call buffer manager( FREE_BUFFER, buffer address) to release the buffer 

containing MU (Appendix B). 

Log the creation failure in the system log. 
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ATTACH_SECURITY_CHECK 


FUNCTION: This procedure performs all security checks on an incoming Attach. 
INPUT : The received Attach (see SNA Formats) 


OUTPUT: A code or sense data value indicating the result of the security check: 


X'FFFFFFFF' local indication of a partner-LU security protocol error 

X'10086040' an Attach parameter is present that is not authorized by the BIND 
security indicators 7 

X'O80F6051' a remote TP security error is found 

X'00000000' the Attach passes all security checks 


All checks within this procedure are required receive checks for implementa- 
tions that support the conversation-level security option. 


If the use of profiles is not supported and one is received, it is ignored. 
If the use of profiles is supported, the option of requiring profiles on every 
Attach versus on Attach only to specific resources is installation-defined. 
If a profile is required on every Attach, connectivity problems with LUs that 
cannot send profiles may result. 


An unauthorized combination of user ID and profile means that the user that 
provides the profile is not permitted to supply that profile. Profiles are 
installation defined at the receiver of the Attach. Profiles assigned to spe- 
cific user IDs are installation defined at the receiver of the Attach. The 
use and interpretation of profiles is not limited to access to secure trans- 
action programs. Profiles may be used to restrict access to resources in 
implementation- and installation-defined ways (e.g., as group IDs). 


this LU does not accept an Already Verified indication in an Attach from the partner LU then 
Return with sense data X'10086040' (Invalid Attach Parameter ). ee 
If the Attach contains security parameters and 
this LU does not accept security parameters in an Attach from the partner LU then 
Return with sense data X'10086040' (Invalid Attach Parameter }. | 
If the target transaction program requires security parameters in an Attach and 
the Attach does not contain security parameters then 
Return with sense data X'O80F6051' (Security Not Valid). 
If the Attach contains no security parameters then 
Return with code X'00000000' (security fields not present nor required). 
If there are multiple security subfields of the same type in the Attach then 
Return with code X'FFFFFFFF' (partner-LU security protocol error). ao 
If there is a security subfield of an unrecognized type then | ; 
Return with code X'FFFFFFFF' (partner-LU security protocol error). C 
If the Attach contains a profile and does not contain a user ID then 
Return with sense data X'O80F6051' (Security Not Valid). 
If the Attach contains a password and does not contain a user ID then 
Return with sense data X'O80F6051' (Security -Not Valid). 
If the Attach indicates end user not already verified and 
the Attach contains a user ID and does not contain a password then 
Return with sense data X'O80F6051' (Security Not Valid). 
If the Attach indicates end user not already verified and | 
the Attach contains an unauthorized combination of user ID and profile or (see note 2) 
the Attach contains an invalid combination of user ID and password then 
Return with sense data X'O80F6051' (Security Not Valid). 
If the Attach indicates end user is already verified and 
the Attach does not contain a user ID or the Attach does contain a password then 
Return with code X'FFFFFFFF' (partner-LU security protocol error). 
If there is limited access to the target transaction program, which is based upon the Attach's 
user ID, and/or profile, and/or the LU name of the Attach sender then 
If the user ID and/or profile and/or partner-LU name is not permitted access 
to this transaction program then 
Return with sense data X'O80F6051' (Security Not Valid). 
Return with code X'00000000' (Attach passes all security checks). 


If the Attach indicates End User Already Verified and C~ 


C- 
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BID_PROC 


FUNCTION: This procedure handles bids for the use of sessions. 


This procedure first checks whether the bid should be rejected because the 
local operator has reset the session limit to 0 with no draining of the part- 
ner LU's requests, and this LU does not support parallel sessions to the part- 
ner LU. In this case, a -BID_RSP(088B) is sent to HS. The -BID_RSP(088B) can 
be sent even if the partner LU is the first speaker. 


If -BID_RSP(088B) is not sent, the procedure checks to see if the requested 
session is free. If so, it removes the session from the free-session pool and 
sends a positive BID_RSP to HS. If the session is not free, it sends a nega- 
tive BID_RSP to HS. 


An implementation may allow a transaction program to reserve a session for its 
own use before the conversation begins. If a session has been reserved, a 
negative BID_RSP is sent to HS even though a conversation has not been started 
on the session. Since the transaction program might never use the reserved 
session (e.g., the transaction program terminates abnormally before the con- 
versation is started), the negative response carries an X'0814¢' sense code 
(Bracket Bid Reject--RTR Forthcoming) to allow the session to be freed, in 
case the reserved session is not needed by a conversation. Reserving a ses- 
sion is implementation dependent and is not shown here. 


INPUT: BID 


OUTPUT : BID_RSP to HS. The RTI field of the BID_RSP is set to either POS or NEG. If 
a protocol error is detected, the session is deactivated. 


NOTE: If RM issues an RTR to the partner LU and receives a positive response to the 
RTR» the HS_ID of the session over which the RTR flows will not be free when 
the BID is received. When RM issued the RTR, it removed that session from the 
free-session pool. When RM sends BIS on a session or when RM bids on a bidder 

"session, that session is removed from the free session pool. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP | page 3-86 

FSM_BIS BIDDER page 3-87 
FSM_BIS_FSP page 3-88 
SEND_DEACTIVATE_SESSION page 3-68 
BID page A-1l 
MODE page A-3 

BID_RSP page A-1l 
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If the state of #FSM_BIS is BIS_RCVD or CLOSED (page 3-87) then 
Call SEND_DEACTIVATE_SESSION( ACTIVE, BID.HS_ID, ABNORMAL, X'20080000') (page 3-68) 
(optional receive check, No Begin Bracket). 
Else 
Get addressability to the MODE control block associated with the LU and 
mode name for the session on which the BID was received. 
If parallel sessions are not supported to the partner LU and 
MODE .SESSION_LIMIT = O and MODE .DRAIN_PARTNER = NO and the state of 
#FSM_BIS (page 3-87) is BIS_SENT then 
Create a BID_RSP record with RTI set to NEG and SENSE_CODE set to 
X'088B0000' and send it to HS (Chapter 6.0). 
Else 
If the state of #FSM_SCB_STATUS is FREE (page 3-84) then 
Call #FSM_SCB_STATUS(R, BID, UNDEFINED) (page 3-84) 
Remove the session from the free-session pool. 
Create a BID_RSP record with RTI set to POS and SENSE_CODE set to 
X'00000000' and send it to HS (Chapter 6.0). 
Else 
If this is a first-speaker session then 
Create a BID_RSP record with RTI set to NEG and SENSE_CODE set to 
X'08130000' or X'08140000' (implementation-dependent choice) 
and send it to HS (Chapter 6.0). 
If SENSE_CODE was X'‘'08140000' then 
Remember that this LU owes RTR to its Lerdner (RTR must be sent to the 
partner LU before it can bid again for this session). 
Else 


Call SEND_DEACTIVATE_SESSION( ACTIVE, BID.HS_ID, ABNORMAL, X'20030000') (page 3-68) 


(optional receive check, Bracket Error). 
Destroy the BID record. 
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FUNCTION: 
Cc 

INPUT: 

OUTPUT: 

NOTES: 1. 
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BID_RSP_PROC 


This procedure handles the processing of responses to bids for the use of 


half-sessions. 


resources manager in response to a pre- 
vious bid for a bidder half-session. In this case, when the input is a posi- 
tive bid response, this procedure calls the appropriate subroutines to cause 
the RCB and SCB to point to each other and to establish the PS and HS con- 
nection. It then informs PS that a session has been’ successfully allocated 
via a SESSION_ALLOCATED record. 


A bid response is usually sent to the 


When the input is a negative bid response, this procedure changes the RCB so 
that it no longer points to the SCB that sent the bid response, and retries 
the GET_SESSION request, which was stored in the RCB when the BID_RQ was 
issued, on another half-session. 


A negative bid response with sense data of X'088B0000' is handled specially. 
This bid response is sent by an LU to indicate that the session limit has been 
reset to 0 for a single-session connection and draining of the partner is not 
allowed. Sending of -BID_RSP(088B) is permitted only in the single-session 
case. 


A -BID_RSP(088B) record may arrive from either a bidder or first-speaker ses- 
sion. If from a bidder session, it 1s in response to a previous bid. If from 
a first-speaker session, no previous bid was sent. A -BID_RSP(088B) record is 
the only bid response that can arrive froma first-speaker session. 


A positive or negative BID_RSP record 

SESSION_ALLOCATED to PS, or GET_SESSION to GET_SESSION PROC (page 3-52) 

When a BID_RQ record is sent to HS, the RCB is’ set to point to the SCB for 
which the bid is being sent; the SCB, however, does not point to the RCB until 


a positive BID_RSP record is received. 


partner LU has reset the session 
requests. The 


record indicates that the 
not permitting draining of the local LU's 


A -BID_RSP(088B ) 
limit to 0O and is 


session is deactivated with UNBIND(Cleanup). 


PS stores in the RCB information that helps HS to set the fields in the 
request/response header (RH). Part of the information states whether the data 
being sent to HS is the beginning of a conversation (in which case HS will set 
BBI)} or is part of an existing conversation (in which case the BBI is set to 
-BB). When RM chooses a bidder half-session to allocate to PS, the 
BID_WITHOUT_ATTACH record that RM sends to HS also triggers HS to set BBI to 
BB. Since PS is unaware of whether RM allocated a bidder or first-speaker 
half-session (and thus does not Know whether the Begin Bracket, which is sent 
only once during a conversation, has already been sent), RM informs PS, in the 
SESSION_ALLOCATED record, as to whether the session assigned to the Allocate 
request is in-bracket (in conversation) or not. 


Referenced procedures, FSMs, and data structures: 


i 
yh 
—_— 


PS page 5.0-8 
HS page 6.0-3 
SEND_DEACTIVATE_SESSION page 3-68 
SET_RCB_AND_SCB_FIELDS page 3-75 
CONNECT_RCB_AND_SCB page 3-42 
GET_SESSION_PROC page 3-52 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
BID_RSP page A-11 
GET_SESSION page A-16 
SCB page A-8 
RCB page A-6 
SESSION_ALLOCATED page A-22 
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If BID_RSP.RTI = NEG and BID_RSP.SENSE CODE = X‘'088B0000' then (see Note 2) 
If the partner LU does not support parallel sessions then 
Reset conwinner, conloser, and session limits for this mode to 0. 
Call SEND_DEACTIVATE_SESSION( ACTIVE, BID_RSP.HS_ID, CLEANUP, X'00000000' ) 
(page 3-68). | 
Else (X'0O88B' valid only from a single-session connection) 
Call SEND_DEACTIVATE_SESSION( ACTIVE, BID_RSP.HS_ID, ABNORMAL, X'‘'20100000' ) 
(page 3-68). 
Else 
Find the RCB associated with the conversation where 
state of #FSM_RCB_STATUS = PENDING _SCB (page 3-89) and 
RCB.HS_ID = BID_RSP.HS_ID. 
If BID_RSP.RTI = POS then 
Call SET_RCB_AND_SCB_FIELDS(RCB.RCB_ID, BID_RSP.HS_ID) (page 3-75). 
Call CONNECT_RCB_AND_SCB(RCB.RCB_ID, BID_RSP.HS_ID, REPLY) (page 3-42). 
Find the SCB associated with the HS that received the BID_RSP. 
Create a SESSION_ALLOCATED record with RETURN_CODE set to OK, 
SEND_RU_SIZE set to SCB.SEND_RU_SIZE, 
LIMITED BUFFER_POOL_ID set to SCB.LIMITED_BUFFER_POOL_ID, 
PERMANENT_BUFFER_POOL_ID set to SCB.PERMANENT_BUFFER_POOL_ID, and 
IN_CONVERSATION set to YES. (Note 3) 
Send the SESSION_ALLOCATED record to the PS that requested the session. 
Else (-RSP(Bid}--retry request on another session) 
Set RCB.HS_ID to a null value. 
Call #FSM_RCB_STATUS(R, NEG_BID_RSP, UNDEFINED) (page 3-89). 
(State of #FSM_RCB_STATUS = FREE). 
If BID_RSP.SENSE_CODE = X'08140000' then 
Remember that the partner LU owes an RTR on this session. 
(Bidder cannot bid again for this session until RTR received). 
Create a GET_SESSION record initialized with the information from the original 
GET_SESSION record, saved in the RCB when the BID record was sent. 
Call GET_SESSION_PROC(GET_SESSION) (page 3-52). 
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BIDDER_PROC 


FUNCTION: This procedure handles the allocation processing for a bidder half-session. 


The HS_ID of the bidder half-session is placed in the RCB of the conversation 
for which the session was requested. The state of #FSM_RCB_STATUS is set to 
indicate that the conversation is pending confirmation that it can use the 
SCB. This procedure then creates a BID_WITHOUT_ATTACH record and sends it to 
HS. 


INPUT: GET_SESSION and HS_ID, the ID of the bidder half-session that was chosen by 
GET_SESSION_PROC (page 3-52) 


OUTPUT: BID_WITHOUT_ATTACH to HS. No SESSION_ALLOCATED record is sent to PS until 
confirmation that the bidder may use the session is received from the 
first-speaker (1.e., until a positive BID_RSP 1s received). 
RCB.#FSM_RCB_STATUS is set to FSM_RCB_STATUS_BIDDER. 


A copy of the GET_SESSION record is created so that, if the bid for the ses- 
ce sion fails, the request can be retried on a different session. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
GET_SESSION page A-16 
HS_ID page 3-91 
BID_WITHOUT_ATTACH page A-17 
RCB page A-6 


Find the RCB identified by GET_SESSION.RCB_ID. 
Set RCB.HS ID to HS_ID. 
= Initialize #FSM_RCB_STATUS to FSM_RCB_STATUS BIDDER (page 3-89). 
‘ Call #FSM_RCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-89). 
2 Save the contents of the GET_SESSION record in the RCB (see Note). 
Build and send a BID_WITHOUT_ATTACH record to HS (Chapter 6.0). 
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BIS _RACE_LOSER 


FUNCTION: This procedure performs the processing necessary when a BIS race occurs and 
this side of the session is the race loser. 


This procedure first decrements the PENDING_TERMINATION_COUNT and issues a 
BIS_REPLY. It then attempts to find another session from the free-session 
pool on which to send a BIS_RQ@. 

INPUT: HS_ID, the ID of the session over which the BIS race occurred 


OUTPUT : BIS_REPLY and, if there is a free session, BIS_RQ to HS, the MODE pending ter- 
mination counts are updated 


NOTE : When the SESSION_DEACTIVATION_POLARITY is EITHER, free first-speaker sessions 
are deactivated in preference to free bidder sessions. | 


Referenced procedures, FSMs, and data structures: 


SEND_BIS_RQ page 3-67 a 
SESSION_DEACTIVATION_POLARITY page 3-74 ( . 
HS page 6.0-3 Se 
HS_ID page 3-91 a 
LU_NAME page 3-91 
MODE_NAME page 3-91 
BIS_REPLY page A-12 
MODE page A-3 


Get addressability to the MODE control block associated with the partner LU and mode name 
of the session identified by HS_ID. 
Decrement MODE .PENDING_TERMINATION_CONWINNERS or MODE.PENDING_TERMINATION_CONLOSERS by 1, 
as appropriate to the session polarity. 
Create a BIS_REPLY record and send it to HS (Chapter 6.0). 
Call SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-74). a 
to determine the polarity of an additional session to deactivate (if any). C 
If there is a free session of the appropriate type then (see Note) ee 
Call SEND_BIS_RQ(HS_ID) (page 3-67). 
Remove the session from the free-session pool. 
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CHANGE_SESSIONS_PROC 


FUNCTION: This procedure performs the processing that is required when two LU service 
transaction programs exchange CHANGE_NUMBER_OF_SESSIONS requests anda new 
session limit is agreed upon. PS.COPR (Chapter 5.4) sends CHANGE_SESSIONS to 
RM after CHANGE_NUMBER_OF_SESSIONS requests have been successfully exchanged. 


A new TERMINATION_COUNT is computed based on the information in_ the 
CHANGE_SESSIONS record. If the new TERMINATION_COUNT is greater than 0, ses- 
sions have to be deactivated. Pending-active sessions are deactivated first 
followed by free sessions. If the TERMINATION_COUNT is still greater than 0; 
sessions will be deactivated later when they become free. 


After pending-active and free sessions have been deactivated as required, 
additional sessions may be activated if the current session count (by polari- 
ty, i.e., CONWINNER or CONLOSER) is less than the minimum limits. This proce- 
dure may have to request both deactivation and activation of sessions if, for 
example, the total session limit remains constant, but the # mix of 
first-speaker and bidder sessions changes. 


INPUT: CHANGE_SESSIONS 


OUTPUT : MODE .TERMINATION count set, waiting GET_SESSION records possibly rejected and 
destroyed, CHANGE_SESSIONS record destroyed 


NOTES: 1. An implementation may choose not to deactivate pending-active sessions. If; 
however, the TERMINATION_COUNT is nonzero when the session becomes active, the 
session has to then be deactivated. 


The MODE pending termination counts indicate the number of sessions that this | 
LU has sent BIS on. | 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
DEACTIVATE_PENDING_SESSIONS page 3-47 
DEACTIVATE_FREE_SESSIONS page 3-46 
ACTIVATE_NEEDED_SESSIONS page 3-24¢ 
CHANGE_SESSIONS page A-15 
MODE page A-3 
GET_SESSION page A-16 
SESSION_ALLOCATED page A-22 


If CHANGE_SESSIONS.RESPONSIBLE is YES then 


Get addressability to the MODE control block associated with CHANGE_SESSIONS.LU_NAME 

and CHANGE_SESSIONS.MODE_NAME. 
Set CONWINNER_COUNT to MODE.ACTIVE_CONWINNERS_COUNT + MODE .PENDING_CONWINNERS_COUNT. 
Set CONLOSER_COUNT to MODE.ACTIVE_CONLOSERS COUNT + MODE .PENDING_CONLOSERS_COUNT. 
Set OLD_SESSION_LIMIT to MODE.SESSION_LIMIT - CHANGE_SESSIONS.DELTA. 
Set PLATEAU to 

min(MODE .ACTIVE_SESSION_COUNT + MODE.PENDING_ SESSION COUNT, OLD_SESSION_LIMIT). 
Set CONWINNER_INCREMENT to the maximum of (0, MODE.MIN_CONWINNERS LIMIT - CONWINNER_COUNT). 
Set SESSION_DECREMENT to the maximum of (0, PLATEAU - MODE.SESSION_LIMIT). 
Set CONLOSER_INCREMENT to the maximum of (0, MODE.MIN_CONLOSERS_LIMIT - CONLOSER_COUNT). 
Set NEED_TO_ACTIVATE to CONWINNER_INCREMENT + CONLOSER_INCREMENT. 
Set ROOM_FOR_ACTIVATION to the maximum of (0, MODE.SESSION_LIMIT - PLATEAU). 
Set DECREMENT_FOR_POLARITY to the maximum of (0, NEED_TO_ACTIVATE - ROOM_FOR_ACTIVATION). 
Set MODE.TERMINATION_COUNT to MODE.TERMINATION_COUNT + SESSION_DECREMENT + 

DECREMENT_FOR_POLARITY. 

If MODE.TERMINATION_COUNT > 0 then 

Call DEACTIVATE_PENDING_SESSIONS(CHANGE_SESSIONS.LU_NAME, CHANGE_SESSIONS.MODE_NAME )} 
(page 3-47, see Note 1). 
If MODE.TERMINATION_COUNT > 0 then 
Call DEACTIVATE_FREE_SESSIONS(CHANGE_SESSIONS.LU_NAME, CHANGE_SESSIONS.MODE_NAME ) 
(page 3-46). 


Chapter 3. LU Resources Manager 3-39 


CHANGE_SESSIONS_PROC 


If MODE.SESSION_LIMIT = 0, and 


(MODE .DRAIN_SELF = NO or (MODE .ACTIVE_SESSION_COUNT - (see Note 2) . 
(MODE .PENDING_TERMINATION_CONWINNERS + MODE .PENDING_TERMINATION_CONLOSERS )=0)) then a 
Do for each GET_SESSION request waiting for a session with (CHANGE_SESSIONS.LU_NAME, Ne? 


CHANGE_SESSIONS.MODE_NAME ): 
Create a SESSION_ALLOCATED record with RETURN_CODE set to UNSUCCESSFUL_NO_RETRY 
and send it to the PS that made the request. 
Destroy the GET_SESSION request. 
Call ACTIVATE_NEEDED_SESSIONS( CHANGE_SESSIONS.LU_NAME, CHANGE _SESSIONS.MODE_NAME) to 
activate new sessions if possible and if needed (page 3-24). 


CHECK_FOR_BIS_REPLY 


FUNCTION: This procedure checks to see if a BIS_REPLY should be sent at the present time 
to respond to a received BIS_RQ. 


INPUT : HS_ID, the ID of the half-session that sent the BIS_RQ 


OUTPUT: BIS REPLY to HS, or no output 


NOTE : BIS REPLY is sent if there are no waiting GET_SESSION requests for the ses- 
sion. 


Referenced procedures, FSMs, and data structures: 


SEND_BIS_REPLY page 3-67 
HS_ID page 3-91 
GET_SESSION . page A-16 
MODE page A-3 
= 
Get addressability to the MODE control block associated with the LU name and mode 
name of the session identified by HS_ID. 7 


If MODE.DRAIN_SELF = NO or there are no GET_SESSION records waiting for the LU name and 
mode name then 
If the session identified by HS_ID is free (between brackets) then 
Call SEND BIS _REPLY(HS_ID) (page 3-67). 
Remove the session from the free-session pool. 
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COMPLETE_LUW_ID 


* COMPLETE_LUW_ID 


FUNCTION: This procedure creates a new LUW instance and sequence number. 


INPUT: TCB 


OUTPUT: The LUW instance and sequence number set in the TCB, PREVIOUS TIME reset 


NOTES: 1. Bits 0-31 of the time value is the accurate local time (S/370 time-of-day 
clock format); the remaining bits, 32-47, may be used to provide uniqueness of 
the LUW instance field. Each LUW instance has a greater value than previously 
generated values. 


If the value of the first 5 bytes found in the TIME variable is equal to the 

value of the last LUW instance (found in PREVIOUS TIME), the value contained 

in bits 32 to 47 of the TIME variable is incremented by 1. Unless bits 32 to 

47 contain all binary l1‘s, incrementing the TIME variable will create a value 

that can be used in the LUW instance field. If bits 32 to 47 contain all 

me binary 1's, the incrementation will cause a wrap, creating an invalid value 

‘ less than the previous time. Under this circumstance, the TIME variable will 

C again be set to the local system time. Implementations should assign bits 32 

to 47 based upon their clock data, when translating their clock into the 370 

clock format, or should treat bits 32 to 47 as a counter to be incremented by 

one whenever the TIME variable is set to the local system time. The counter 

may be initialized to binary 0's. When all bits 32 to 47 are set (binary 1's) 

and the time function is called again, the counter should wrap (all bits 32 to 
G7 as binary 0) with no carry past bit 32. 


Referenced procedures, FSMs, and data structures: 


TCB page A-9 
PREVIOUS_TIME page 3-92 
yor TIME, see PREVIOUS _TIME page 3-92 
\ 
\ Repeat until a valid TIME is generated 


Set TIME variable to the local system time. 
Translate TIME variable to IBM S/370 time-of-day clock format. 
(Refer to SYSTEM/370 Principles of Operation, <GA22-7000>, for the defined format. ) 
If TIME(bits 0 to 47) is less than or equal to PREVIOUS_TIME (Note 1) 
and the TIME value has not wrapped then 
Add binary 1 to the TIME(bits 32 to 47) value. (Note 2) 
If TIME( bits 32 to 47) has wrapped then 
TIME is not valid. 
Else 
TIME is valid. 


oe Else 

= TIME is valid. 
Set TCB.LUW_IDENTIFIER.LUW_INSTANCE to TIME(bits 0 to 47). 
Set PREVIOUS TIME to TIME(bits 0 to 47). 
Set TCB.LUW_IDENTIFIER.LUW_SEQUENCE_NUMBER to l. 


ae 


a 
~ 
‘sy 
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CONNECT_RCB_AND_SCB 


CONNECT_RCB_AND_SCB | we 
| | 
Se 


FUNCTION: This procedure connects a PS and HS process, and informs HS when’ the con- 
nection is complete. 


INPUT: RCB_ID and HS_ID, the IDs.of the RCB representing the conversation resource 
and the SCB representing the half-session 


OUTPUT : The RCB and SCB are updated; HS_PS_CONNECTED record is sent to HS. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 

RCB page A-6 

SCB page A-8 

RCB_ID page 3-91 

HS_ID 2 page 3-91 

HS_PS_ CONNECTED page A-18 
Find the half-session (SCB) identified by HS_ID. ( ~ 
Find the conversation (RCB) identified by RCB_ID. ey 


Set RCB.SESSION_IDENTIFIER to SCB.SESSION_IDENTIFIER. 

Set SCB.BRACKET_ID to RCB.BRACKET_ID. 

Create an HS_PS_ CONNECTED record with BRACKET_ID set to RCB.BRACKET_ID 
and PS_ID equal to RCB.TCB_ID. 

Send the record to HS. (Chapter 6.0). 
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CREATE_RCB 


CREATE_RCB 


FUNCTION: This procedure handles the creation of new RCBs_ for outgoing ALLOCATE 
requests, for incoming Attaches see (PS_CREATION_PROC on page 3-55). 


INPUT: ALLOCATE_RCB and RCB_ALLOCATED. The RCB_ALLOCATED was created by ALLO- 
CATE_RCB_PROC (page 3-26). 


OUTPUT: RCB_ALLOCATED with the RCB_ID field set to the ID of the new RCB; an RCB is 
created and initialized. 


NOTE : #FSM_RCB_STATUS is a generic FSM that can be either FSM_RCB_STATUS_FSP or 
FSM_RCB_STATUS_BIDDER, depending on whether the conversation resource is using 
a first-speaker or a bidder half-session. When a new RCB is created, it is 
not usually Known which type of half-session will be available (except for 
ALLOCATE_RCBC IMMEDIATE), which must use a_ first-speaker half-session in order 
to be successful). Therefore, when the RCB is created, the FSM is initialized 
to FSM_RCB_STATUS_FSP, and is changed later if the conversation will be run- 
ning on a bidder half-session. Until this determination is made, the state of 
the #FSM_RCB_STATUS remains FREE (01). 


Referenced procedures, FSMs, and data structures: 


FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
ALLOCATE_RCB page A-15 
RCB_ALLOCATED page A-21 
TCB page A-9 
RCB page A-6 


Create RCB, initializing RCB_ID and BRACKET_ID to unique values, HS_ID to a null value, 
LU_NAME to ALLOCATE_RCB.LU_NAME, and MODE_NAME to ALLOCATE_RCB.MODE_NAME. 

Copy TCB_ID, SYNC_LEVEL, and SECURITY_SELECT from the ALLOCATE_RCB record to the RCB. 

Set RCB_ALLOCATED.RCB_ID to RCB.RCB_ID. 

Set #FSM_RCB_STATUS = FSM_RCB_STATUS FSP (page 3-90; see Note). 

Call #FSM_RCB_STATUS(S, ALLOCATE_RCB, UNDEFINED) 

page 3-89). 

Set RCB.CONVERSATION_CORRELATOR to a unique value, RCB.SESSION_IDENTIFIER to a null value, 
RCB.TP_NAME to the TRANSACTION _PROGRAM_NAME in the TCB specified by ALLOCATE RCB. 
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CREATE_SCB 
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CREATE_SCB 


FUNCTION: This procedure creates a new SCB based on the LU_NAME, MODE_NAME, 


SION_INFORMATION arguments. 


INPUT: LU_NAME and MODE_NAME of the partner LU; and SESSION_INFORMATION; 
| describes the session attributes 


OUTPUT: A new SCB is created. 


Referenced procedures, FSMs, and data structures: 


FSM_SCB_STATUS_BIDDER page 
FSM_SCB_STATUS_FSP page 
FSM_BIS_BIDDER page 
FSM_BIS_FSP page 
LU_NAME page 
MODE_NAME | page 
SESSION_INFORMATION page 
SCB page 


Create an SCB, set SCB.HS_ID to SESSION_INFORMATION.HS_ID, SCB.LU_NAME to 
LU_NAME, SCB.MODE_NAME to MODE_NAME, SCB.RCB_ID to a null value, 
SCB.SESSION_IDENTIFIER to SESSION_INFORMATION.SESSION_IDENTIFIER, 
SCB.SEND_RU_SIZE to SESSION_INFORMATION.SEND_RU_SIZE, 
SCB.LIMITED_BUFFER_POOL_ID to SESSION_INFORMATION.LIMITED_BUFFER_POOL_ID, 
SCB.PERMANENT_BUFFER_POOL_ID to SESSION_INFORMATION.PERMANENT_BUFFER_POOL_ID;, 
SCB.BRACKET_ID to null, SCB.RANDOM_DATA to SESSION_INFORMATION.RANDOM_DATA, 
and SCB.RTR_OWED to FALSE. 

Select based on SESSION_INFORMATION.BRACKET_TYPE: 

If the half-session is a first-speaker then 

Assign finite-state machines to be used by setting 
#FSM_BIS to FSM_BIS_FSP (page 3-88) 

and #FSM_SCB_STATUS to FSM_SCB_STATUS FSP (page 3-86). 
Set SCB.FIRST_SPEAKER to TRUE. 

Else (bidder session) 

Assign finite-state machines to be used by setting 
#FSM_BIS to FSM_BIS_BIDDER (page 3-87) 

and #FSM_SCB_STATUS to FSM_SCB STATUS BIDDER (page 3-85). 
Set SCB.FIRST_SPEAKER to FALSE. 
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CREATE_TCB_AND_PS 


_ CREATE_TCB_AND_PS 
+ 


FUNCTION: This procedure creates a TCB and PS as a result of START_TP processing. 


INPUT: The START_TP request record, a non-null TRANSACTION_PROGRAM record 


OUTPUT: A new TCB and PS; and the START_TP with the new TCB_ID. All shared TCB fields 
are initialized in this procedure. When a PS creation failure occurs, the TCB 
is destroyed, START_TP.TCB_ID is set to null, and the failure is logged. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
TCB page A-9 
START_TP page A-19 
LUCB page A-1 
PS_CREATE_PARMS page A-27 
TRANSACTION_PROGRAM page A-5 
COMPLETE_LUW_ID page 3-41 


S Create a TCB. 


Set TCB.TCB_ID to a unique value. 

Set TCB.TRANSACTION_PROGRAM_NAME to START_TP.TARGET_TP_NAME. 

Set TCB.OWN_LU_ID to LUCB.LU_ID. 

Set TCB.LUW_IDENTIFIER. FULLY_QUALIFIED_LU_NAME to START_TP.FULLY_QUALIFIED_LU_NAME. 

Call COMPLETE_LUW_ID(TCB) (page 3-41). 

Set TCB.CONTROLLING_COMPONENT to TP. 

If a user ID is present in the START_TP then 

Set TCB. INITIATING SECURITY.USERID to START_TP.SECURITY.USERID. 

Else | 
Set TCB.INITIATING_SECURITY.USERID to null. 

If a profile is present in the START_TP then 


S Set TCB.INITIATING_SECURITY.PROFILE to START_TP.SECURITY .PROFILE. 
| Else 
ea Set TCB.PROFILE to null. 


Create PS _CREATE_PARMS initializing the fields to the addresses and IDs of 
of the data structures to which PS requires access (See page A-27). 
Create a new PS process with the PS_CREATE_PARMS as parameter (Chapter 5.0). 
If PS was successfully created then 

Increment TRANSACTION_PROGRAM. INSTANCE COUNT by 1. 

Set START_TP.TCB_ID to TCB.TCB_ID. 
Else 

Destroy the TCB. 

Log the PS creation failure to the system log. 

Set START_TP.TCB_ID to a null value. 
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DEACTIVATE_FREE_SESSIONS 


FUNCTION: This procedure requests deactivation of free sessions between this LU and the 
partner LU identified by (LU_NAME, MODE_NAME). Deactivations are requested 
until either all free sessions have had deactivation requested, or this LU is 
not responsible for any more deactivations. 


INPUT: The LU_NAME of the partner LU and the MODE_NAME of the sessions to be deacti- 
vated 


OUTPUT : Zero or more sessions are removed from the free-session pool. 


NOTE: First-speaker sessions are deactivated before bidder sessions. 


Referenced procedures, FSMs, and data structures: 


SESSION _DEACTIVATION_POLARITY | page 3-74 
SEND_BIS | page 3-66 
SCB page A-8& 
LU_NAME page 3-91 
MODE_NAME ; page 3-91 


Do while there exists a free session of a polarity matching that returned by 
SESSION DEACTIVATION _POLARITY(LU_NAME, MODE_NAME) (page 3-74): 
(If SESSION_DEACTIVATION_POLARITY returns EITHER, a first-speaker session is 
deactivated in preference to a bidder session. } 
Find the session's corresponding SCB. 
Remove the session from the free-session pool. 
Call SEND _BIS(SCB.HS_ID) (page 3-66). 
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DEACTIVATE_PENDING_SESSIONS 


DEACTIVATE_PENDING_SESSIONS 


FUNCTION: This procedure requests deactivation of pending-active sessions between this 
LU and the partner LU identified by (LU_NAME, MODE_NAME). Deactivations are 
requested until either all pending-active sessions have had deactivation 
requested, or this LU is not responsible for any more deactivations. 


INPUT: LU_NAME of the partner LU and the MODE_NAME of the sessions to be deactivated 


OUTPUT: MODE termination count decremented, queued RM_ACTIVATE_SESSION requests 
destroyed, RM_SESSION_ACTIVATED records created and sent to PS 


NOTE: Deactivation requests for pending-active sessions are type Cleanup. This 
addresses the possiblity that the session may already be established without 
RM yet Knowing (via ACTIVATE_SESSION_RSP). Under this circumstance, the type 
of UNBIND sent should be Cleanup. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
SESSION_DEACTIVATION_POLARITY page 3-74 
SEND_DEACTIVATE_SESSION page 3-68 
PENDING ACTIVATION, see ACTIVATE_SESSION page A-20 
LU_NAME | page 3-91 
MODE_NAME page 3-91 
MODE page A-3 
RM_SESSION_ACTIVATED page A-22 
RM_ACTIVATE_SESSION page A-16 


Get addressability to the MODE control block associated with (LU_NAME, MODE_NAME ). 
Do while there are PENDING_ACTIVATION records for first-speaker sessions | 
for (LU_NAME, MODE_NAME), and SESSION_DEACTIVATION_POLARITY( LU_NAME ,MODE_NAME ) 
(page 3-74) indicates FIRST_SPEAKER or EITHER: 
Call SEND_DEACTIVATE_SESSION( PENDING, PENDING_ACTIVATION.CORRELATOR, CLEANUP, X'08A00002' ) 
(page 3-68). 
Decrement MODE.TERMINATION_COUNT by 1. 
Do while there are PENDING_ACTIVATION records for bidder sessions 
for (LU_NAME, MODE_NAME), and SESSION_DEACTIVATION_POLARITY( LU_NAME ,MODE_NAME ) 
(page 3-74) indicates BIDDER or EITHER: 
Call SEND DEACTIVATE_SESSION( PENDING, PENDING _ACTIVATION.CORRELATOR, CLEANUP, X'08A00002' ) 
(page 3-68). 
Decrement MODE.TERMINATION_COUNT by 1. 
Do while the number of pending CNOS operator activation requests 
for (LU_NAME ,MODE_NAME) > MODE.PENDING_SESSION_COUNT: 
Find a pending operator RM_ACTIVATE_SESSION request for (LU_NAME ,MODE_NAME ). 
Create an RM_SESSION_ACTIVATED with RETURN_CODE equal to LU_MODE_SESSION_LIMIT_EXCEEDED 
and send it to the PS that sent the request. 
Discard the pending operator RM_ACTIVATE_SESSION request. 
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DEQUEUE_WAITING_REQUEST 


FUNCTION: This procedure checks to see if any eligible GET_SESSION requests are waiting 


to be serviced. the first eligible request and 


HS_ID, the ID of the half-session that sent the request 


GET_SESSION_PROC is 


Referenced procedures, FSMs, and data structures: 


GET_SESSION_PROC 
GET_SESSION 


MODE 
HS_ID 


Get addressability to the MODE of the session identified by HS_ID.: 
If there is a waiting GET_SESSION request for a session on this MODE then 
Remove the GET_SESSION from the waiting request queue. 
Call GET_SESSION_PROC(GET_SESSION) (page 3-52) to service the request. 


SNA LU 6.2 Reference: 


Peer Protocols 


This procedure dequeues 
_ invokes GET_SESSION_PROC (page 3-52) to process the request. 


invoked to process the waiting 
request is removed from the waiting request list. 


“request and the waiting 


page 3-52 
page A-16 
page A-3 


page 3-91 


‘4 
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FIRST_SPEAKER_PROC 


FIRST_SPEAKER_PROC 


FUNCTION: 


This procedure handles the allocation processing for a _ first-speaker 
half-session. 


This procedure causes the SCB associated with the first-speaker half-session 
and the RCB of the conversation for which the session was requested to be con- 


nected to each other. RM creates a SESSION_ALLOCATED record, which it sends 
to PS to inform PS that a session has been successfully allocated. 


GET_SESSION and HS_ID, the ID of the first-speaker half-session that was cho- 
sen by GET_SESSION_ PROC (page 3-52) 


SESSION_ALLOCATED to PS 


Referenced procedures » FSMs» and data structures: 


PS page 5.0-8 
SET_RCB_AND_SCB_FIELDS page 3-75 
CONNECT_RCB_AND_SCB page 3-42 
GET_SESSION page A-16 
SESSION_ALLOCATED page A-22 
HS_ID page 3-91 
SCB page A-8 


Call SET_RCB_AND_SCB_FIELDS(GET_SESSION.RCB_ID, HS_ID) (page 3-75). 

Call CONNECT_RCB_AND_SCB(GET_SESSION.RCB_ID, HS_ID) (page 3-42). 

Create a SESSION_ALLOCATED record with RETURN_CODE equal to OK. 

Get addressability to the SCB identified by HS_ID. 

Set SEND_RU_SIZE, LIMITED_BUFFER_POOL_ID, and PERMANENT_BUFFER_POOL_ID 
in the SESSION_ALLOCATED record to the corresponding fields in the SCB. 

Set SESSION_ALLOCATED.IN_CONVERSATION to NO. 

Send the record to PS. 
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FREE_SESSION_PROC 


This procedure handles the processing that occurs when a session becomes free. 


This procedure first checks to see if a Bid is outstanding on this session. 
If so, the session is not returned to the free-session pool. If not, the pro- 
cedure checks to see if an RTR_RQ or a BIS request or reply is to be sent. If 
either RTR_RQ or BIS is sent, the session is not returned to the free-session 
pool. If neither BIS nor RTR is sent, the free-session is returned to the 
free-session pool, and a waiting session allocation request (if any) is serv- 
iced. : 


INPUT : FREE_SESSION 


OUTPUT : BRACKET_FREED, BIS_RQ, BIS_REPLY, or RTR_RQ to HS; or GET_SESSION to 
GET_SESSION_PROC (page 3-52); or no output 


NOTES: 1. Upon receipt of DEALLOCATE_RCB (a request to deallocate the conversation) from 
PS, RM destroys the RCB associated with the conversation previously using the 
half-session (see PROCESS _PS_TO_RM_RECORD on page 3-22). If the search for 
the RCB identified by the SCB.RCB_ID fails, PS has already deallocated the 
conversation. When this occurs, RM sends BRACKET_FREED to the half-session. 


If an RTR is owed on this session (either the partner LU owes RTR to the local 
LU or the local LU owes RTR to the partner), the bidder has to wait for an RTR 
from the first-speaker before it can again bid for the session. Therefore, 
the deallocated bidder session is not returned to the free-session pool and a 
waiting request is not serviced. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
DEQUEUVE_WAITING_REQUEST page 3-48 
SHOULD_SEND_BIS page 3-76 7 
SEND_BIS page 3-66 e 
SEND_DEACTIVATE_SESSION page 3-68 wy 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 

FSM_BIS_ BIDDER page 3-87 

FSM_BIS_FSP | page 3-88 

BRACKET_FREED page A-18 

FREE_SESSION page A-12 

SCB page A-8 

RCB page A-6 

RTR_RQ page A-12 _ 
GET_SESSION page A-16 A 


3-50 SNA LU 6.2 Reference: Peer Protocols 


FREE_SESSION_PROC 


Find the SCB associated with the session identified by FREE_SESSION.HS_ID. 
Find the RCB identified by the SCB.RCB_ID. 
If the RCB cannot be found (Note 1) then 
Create a BRACKET_FREED record, initializing the BRACKET_ID to SCB.BRACKET_ID. 
Send the BRACKET_FREED record to the HS that sent the FREE_SESSION. 
Set SCB.RCB_ID to a null value. 
If the state of #FSM_SCB_STATUS is PENDING_FMH12 then (page 3-84). 
Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL; X'O80F6051') (page 3-68). 
Optionally log an error in the system log. 
Return to the calling routine. 
Else 
Call #FSM_SCB_STATUS(R, FREE_SESSION, UNDEFINED) (page 3-84). 
If there is an RCB for which the state of #FSM_RCB_STATUS is PENDING_SCB, 
and RCB.HS_ID = SCB.HS_ID then 
Take no action and return to the calling routine (a Bid is pending). 
If SCB.RTR_OWED is TRUE then 
If this is a first-speaker session (1.e., this LU owes RTR) then 
If there are no waiting GET_SESSION requests for a session 
of the partner LU and of the mode of the free session then 
If RTR is to be sent now (implementation-defined choice) then 
Send RTR_RQ to HS (Chapter 6.0). 
Set SCB.RTR_OWED to false. 
Else 
Return the session to the free-session pool. 
Return to the calling routine. 
Else (bidder session; i.e., other LU owes RTR) 
Take no action and return to the calling routine (Note 2). 
Call SHOULD_SEND_BIS(SCB.HS_ID) (page 3-76) to determine 
whether BIS should be sent now. 
If BIS should be sent now then 
Call SEND _BIS(SCB.HS_ID) (page 3-66). 
If the state of #FSM_BIS (page 3-87) is BIS_SENT or CLOSED then 
Take no action and return to the calling routine (BIS has been sent). 
Else (the session is available for reuse) 
Return the session to the free-session pool. 
If there are waiting GET_SESSION requests for this (partner LU, mode) then 
Call DEQUEUE_WAITING_REQUEST(SCB.HS_ID) (page 3-48). 
Destroy the FREE_SESSION record. 
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3-52 


GET_SESSION_PROC 


This procedure handles the allocation of half-sessions to be used by conversa- 
tion resources. 


The procedure checks for an available half-session and calls the appropriate 
procedure, depending upon whether the half-session found was a first-speaker 
or a bidder half-session. If no half-sessions are available and the current 
session limit has not been reached, SEND_ACTIVATE_SESSION is called» which 
requests that SM activate a new session. i 


INPUT : GET_SESSION 


OUTPUT: See called procedures for output. 


NOTES: 1. RM does the following: attempts to service the request with a first-speaker 
half-session; if none is available, RM attempts to service the request with a 
bidder half-session; failing that, RM requests the session manager to activate 
a new session if the current session limit has not been reached. If a 
first-speaker half-session is available, that session is used to service the 
session request. If no first-speaker half-sessions are available, an imple- 
mentation can choose to service the request with a free bidder half-session;, 
activate a new first-speaker half-session, or both of the above. An implemen- 
tation could, for example, choose to implement the following order: choose a 
free first-speaker half-session; request a new first-speaker half-session be 
activated; and, finally, choose a free bidder half-session. (Another possi- 
bility is that an implementation could service the session request with a bid- 
der half-session, if no first-speaker half-sessions are available, but at the 
same time ask that a new first-speaker half-session be activated.) However, 
if there are no free first-speaker half-sessions and the session limit for the 
desired (LU name, mode name) pair has been reached, the session request is 
serviced with a bidder half-session, if available. If a bidder half-session 
is available, an implementation does not wait for a first-speaker half-session 
to become free before servicing the session request. 


2. A mode is closed if no sessions are active for the mode name and a session 

cannot be activated without operator intervention (e.g., the operator must 
increase the session limit above 0). In this case, the GET_SESSION request is 
rejected with a return code of UNSUCCESSFUL_NO_RETRY. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
FIRST_SPEAKER_PROC page 3-49 
BIDDER_PROC page 3-37 
SESSION_ACTIVATION_POLARITY page 3-71 
SEND_ACTIVATE_SESSION page 3-65 
SEND_BIS page 3-66 
GET_SESSION page A-16 
RCB page A-6 
SCB page A-8& 
PARTNER_LU page A-2 
SESSION_ALLOCATED page A-22 
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GET_SESSION_PROC 


Find the RCB with RCB_ID equal to GET_SESSION.RCB_ID. 

Find the PARTNER_LU identified by the RCB.LU_NAME. 

Find the MODE identified by the RCB.LU_NAME and RCB.MODE_NAME. 
If the mode is closed then (see Note 2) 


Create and send a SESSION_ALLOCATED record with a return code of UNSUCCESSFUL_NO_RETRY to 


PS (Chapter 5.1). 
Destroy the GET_SESSION record. 


Else 
If the (RCB.LU_NAME, RCB.MODE_NAME) sessions do not support the 


requested sync level then 


Create and send SESSION_ALLOCATED record with a return code of SYNC_LEVEL_NOT_SUPPORTED. 


Destroy the GET_SESSION record. 
Else 
If the (RCB.LU_NAME, RCB.MODE_NAME) sessions do not support the 
requested security level then 
Downgrade the SECURITY_SELECT field of the RCB by setting it to NONE. 
If a free session exists for RCB.LU_NAME and RCB.MODE_NAME then 
Find the SCB associated with the free session. 
If SCB.FIRST_SPEAKER is YES then 
Call FIRST_SPEAKER_PROC(GET_SESSION, SCB.HS_ID) (page 3-49). 
Destroy the GET_SESSION record. 
Else (bidder half-session) 
Call BIDDER_PROC(GET_SESSION, SCB.HS_ID) (page 3-37). 
Remove the session from the free-session pool. 
Else (no free session exists) 
If the number of waiting GET_SESSION requests queued for sessions 


on this mode equals or exeeds the number of pending active session requests then 
Call SESSION_ACTIVATION_POLARITY(RCB.LU_NAME, RCB.MODE_NAME) (page 3-71) 


to determine the polarity of the next activated session (if any). 
Select based on session activation polarity: 
When NONE (no new sessions can be activated) 


If PARTNER_LU.PARALLEL_SESSSION is NOT_SUPPORTED and an active session 


for another mode exists (other than the mode requested by the 


GET_SESSION) then 
If the session is free then 
Get addressability to the SCB of the free session. 
Remove the session from the free session pool. 
Call SEND_BIS(SCB.HS_ID) (page 3-66). 
When FIRST_SPEAKER 
Call SEND_ACTIVATE_SESSION(RCB.LU_NAME, RCB.MODE_NAME, 
FIRST_SPEAKER) (page 3-65). 
When BIDDER 
Call SEND_ACTIVATE_SESSION(RCB.LU_NAME, RCB.MODE_NAME ; 
BIDDER) (page 3-65). 
Queue the GET_SESSION request to await a session. 
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PS_ABEND_PROC 


FUNCTION: This procedure recovers from a PS abend. 


The procedure deletes the control blocks, data structure entries, and counts 
associated with the abended PS. 


ABEND_NOTIFICATION 


Queued GET_SESSION requests from the abended PS are destroyed, RCB control 
blocks and the TCB control block associated with the abended PS are destroyed, 
the sessions that the PS was using or bidding on are unbound, the TP instance 
count associated with the abended PS is decremented, queued Attach and 
START_TP requests for the TP are recycled by updating associated control 
blocks and recalling the appropriate procedure. 


In order to recall ATTACH_PROC the state of the SCB FSM must be PEND- 


ING_ATTACH. Both FSM calls are needed to change the state of the FSM from 
IN_USE to PENDING_ATTACH. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
SM page 4-48 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP | page 3-86 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
SESSION_DEACTIVATED_PROC page 3-72 
ATTACH_PROC page 3-30 
START_TP_PROC page 3-77 
TCB page A-9 
SCB page A-8 
ABEND_NOTIFICATION page A-25 
RCB | page A-6 
DEACTIVATE_SESSION page A-21 
TRANSACTION_PROGRAM | page A-5 
MU page A-29 
START_TP page A-19 
SESSION_DEACTIVATED page A-14 
MODE . page A-3 


GET_SESSION - page A-16 


Find the TCB representing the abended PS. 
Destroy all queued GET_SESSION requests from the abended PS. 
If the TCB is found 
Do for each RCB associated with the abended PS: 
If the state of the associated FSM_RCB_STATUS is FREE then 
Find the MODE that corresponds to RCB.LU_NAME, RCB.MODE_NAME 


If the state of the associated FSM_RCB_STATUS is IN_USE or PENDING_SCB then 
Find the SCB with HS_ID equal to RCB.HS_ID. 
Destroy the RCB. 
If the SCB is found then 
Create a DEACTIVATE_SESSION with STATUS set to ACTIVE, 
HS_ID set to SCB.HS_ID, TYPE set to ABNORMAL, and 
SENSE_CODE set to X'08640000'. 
Send the DEACTIVATE_SESSION record to SM. 
Create a SESSION_DEACTIVATED with HS_ID set to SCB.HS_ID;, 
REASON set to ABNORMAL_RETRY, and SENSE_CODE set to X'08640000'. 
Call SESSION_DEACTIVATED_PROC(SESSION_DEACTIVATED) (page 3-72). 
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PS_ABEND_PROC 


Find the TRANSACTION_PROGRAM where TRANSACTION PROGRAM. TRANSACTION_PROGRAM_NAME equals 
eC . the TCB.TRANSACTION_PROGRAM_NAME of the abended PS. 
; If the TRANSACTION_PROGRAM is found then 
SS Decrement the TRANSACTION_PROGRAM. INSTANCE_COUNT by 1. 

If there is an initiation request (Attach or START_TP) queued for the transaction 
program named by TRANSACTION_PROGRAM.TRANSACTION_PROGRAM_NAME and the 
TRANSACTION_PROGRAM. INSTANCE COUNT is less than the TRANSACTION_PROGRAM. INSTANCE_LIMIT 
then 

Remove the initiation request from the queue. 
If the initiation request is an MU (containing an Attach) then 
Find the RCB with RCB_ID equal to MU.RM_TO_PS.RCB_ID. 
Set MU.HS_TO_RM.HS_ID to the RCB's HS _ID. 
Find the SCB with the HS_ID equal to the RCB‘s HS_ID. 
Call FSM_SCB_STATUS(R, FREE_SESSION, UNDEFINED). 
Call FSM_SCB_STATUS(R, BID, UNDEFINED) (See Note). 
Set the SCB's BRACKET_ID and RCB_ID to null. 
Destroy the RCB. 
Call ATTACH_PROC(MU) (page 3-30) 
If the queued initiation request is a START_TP then 
Call START_TP_PROC(START_TP) (page 3-77). 
Log the abend to the system log. 
C Destroy the TCB of the abended PS. 
/ 


PS _CREATION_PROC 


FUNCTION: This procedure creates a new PS process. 


This procedure is called upon receipt of an Attach. Along with creating the 

PS process, it also creates a new TCB and RCB. It returns to the calling pro- 

| a | cedure the IDs of the newly created TCB and RCB, which the calling procedure 
} will send to PS along with the received MU containing an Attach. 


An MU containing an Attach, variables in which the TCB_ID and RCB_ID will be 
returned, and the pointer to the TRANSACTION_PROGRAM structure that represents 
the target transaction program 


OUTPUT: A TCB, RCB; and new PS' process created and initialized, CREATE_RC (creation 
return code, SUCCESS or FAILURE) is set and returned to the calling 
proceedure, if the creation fails, the TCB and RCB destroyed, if the creation 
succeeds, the transaction program instance count incremented 


- Referenced procedures, FSMs, and data structures: 

Ng PS page 5.0-8 
COMPLETE_LUW_ID | page 3-41 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
TRANSACTION_PROGRAM page A-5 
PS_CREATE_PARMS page A-27 
MU page A-29 
TCB_ID page 3-91 
RCB_ID page 3-91 
TCB page A-9 
SCB page A-8& 
RCB page A-6 
LUCB page A-1 


Create a TCB with a unique TCB_ID, initializing TRANSACTION_PROGRAM_NAME to the 
transaction program name contained in the Attach, CONTROLLING_COMPONENT to TP 
and OWN_LU_ID to LUCB.LU_ID. 

If the Attach contains a user ID then 

Set TCB.INITIATING_SECURITY.USERID to the user ID contained in the Attach. 


Else ; 
ae Set TCB.INITIATING_SECURITY.USERID to null. 
C) If the Attach contains a profile then 
Set TCB.INITIATING_SECURITY.PROFILE to the profile contained in the Attach. 
Else 


Set TCB.INITIATING_SECURITY.PROFILE to null. 
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If the Attach contains a logical-unit-of-work ID then 
Save the logical-unit-of-work ID from the Attach in the TCB. 
Else 
Set the TCB.LUW_IDENITFIER.FULLY_QUALIFIED_LU_NAME to the LUCB.FULLY_QUALIFIED_LU_NAME. 
Call COMPLETE_LUW_ID(TCB) (page 3-41). 
Find the SCB identified by MU.HS_TO_RM.HS_ID. 
Create an RCB with a unique RCB_ID, initializing RCB.TCB_ID to TCB.TCB_ID, 
RCB.LU_NAME to SCB.LU_NAME, RCB.MODE_NAME to SCB.MODE_NAME, 
TP_NAME to the transaction program name contained in the Attach, 
RCB.BRACKET_ID to a unique value, RCB.SYNC_LEVEL to the sync level of the Attach, 
and RCB.HS_TO_PS _BUFFER_LIST to empty. 
If a conversation correlator is present in the Attach then 
Set the RCB.CONVERSATION_CORRELATOR to the conversation correlator in the Attach. 
Else 
Set the RCB.CONVERSATION CORRELATOR to null. 
If the session is a first speaker then 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_FSP (page 3-90). 
Else 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_BIDDER (page 3-89). 
Call #FSM_RCB_STATUS(R, ATTACH, HS) (page 3-89). 
Set RCB.HS_ID to MU.HS _TO_RM.HS_ID. 
Create PS_CREATE_PARMS initializing the fields to the addresses and IDs of 
of the data structures to which PS requires access (See page A-27). 
Create a new PS process with the PS_CREATE_PARMS as a parameter 
If PS was successfully created then 
Set CREATE_RC to SUCCESS. 
If the pointer to TRANSACTION_PROGRAM is a non-null value then 
Increment TRANSACTION_PROGRAM. INSTANCE _COUNT by 1. 
Else 
Set CREATE_RC to FAILURE. 
Destroy the TCB and RCB. 
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PS_TERMINATION_PROC 


« 


FUNCTION: This procedure handles the termination of a PS process. 


INPUT: 


OUTPUT : 


NOTES: 


If there are no queued Attach or START_TP requests for this TP, the procedure 
destroys the PS process and discards the TCB corresponding to the PS being 
destroyed. If there are waiting requests for the TP-PS process, PS is 
normally not terminated, instead the waiting request is sent to the PS 
instance requesting termination. 


TERMINATE_PS 


The PS process is destroyed , or an MU (containing an FMH-5) is sent to PS and 
HS_PS_ CONNECTED is sent to HS, or a START_TP record is sent to the PS process 


1. TRANSACTION_PROGRAM will not exist when the PS instance was brought up to 
reject an Attach that specified an unknown transaction program name. Under 
this circumstance the instance count for a transaction program has no meaning. 


The TP instance count may exceed the instance limit when a PS process is 
brought up to reject an Attach that contained an error (except as noted 
above). When the instance limit is exceeded, the PS process is terminated 
regardless of any queued requests. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
HS page 6.0-3 
TERMINATE_PS | page A-17 
LUCB page A-1 
TRANSACTION _PROGRAM page A-5 
HS_PS_ CONNECTED page A-18 
MU page A-29 
START_TP page A-19 
START_TP_REPLY page A-20 
TCB page A-9 
RCB page A-6 
COMPLETE_LUW_ID page 3-41 


Find the TCB ‘and TRANSACTION_PROGRAM corresponding to the PS being destroyed 
If a TRANSACTION_PROGRAM is found (Note 1) and ; 
if there are queued waiting initiation requests for the TRANSACTION_PROGRAM and 
the TRANSACTION_PROGRAM.INSTANCE_LIMIT = TRANSACTION_PROGRAM. INSTANCE COUNT then (Note 2) 
Select based on the first queued request's record type: 
When MU (MU containing an Attach) 


Set the MU.RM_TO_PS.TCB_ID to TCB.TCB_ID. 
Set the TCB.CONTROLLING_COMPONENT to TP. 
If the security subfields are present in the Attach then 
Set the TCB.INITIATING_SECURITY fields (PROFILE and USERID) to the values 
contained in the corresponding fields of the Attach. 
If an LUW_IDENTIFIER is present in the Attach then 
Set TCB.LUW_IDENTIFIER to the corresponding Attach field. 
Else (LUW_IDENTIFIER not in Attach) 
Set the TCB.LUW_IDENTIFIER.FULLY_QUALIFIED_LU_NAME to 
LUCB.FULLY_QUALIFIED_LU_NAME. 
Call COMPLETE_LUW_ID(TCB) (page 3-41). 
Find the RCB with RCB_ID equal to MU.RM_TO_PS.RCB_ID. 
Set RCB.TCB_ID to TCB.TCB_ID. 
Create an HS_PS_ CONNECTED record with BRACKET_ID set to RCB.BRACKET_ID 
and PS_ID set to RCB.TCB_ID. 
Send the HS_PS_CONNECTED record to HS. 
Send the MU to PS. 
If the send to PS fails then 
Call buffer manager (FREE_BUFFER, buffer address) to release 
the buffer containing MU. ("Appendix B. Buffer Manager" ) 
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When START_TP 
Set START_TP.TCB_ID to TCB.TCB_ID. 
Set the TCB.LUW_IDENTIFIER.FULLY_QUALIFIED_LU_NAME to 
START_TP.FULLY_QUALIFIED_LU_NAME. 
Call COMPLETE_LUW_ID(TCB) (page 3-41). 
Set the TCB.CONTROLLING_COMPONENT to TP. 
If the START_TP.SECURITY_SELECT is PGM then 
Set the TCB.INITIATING_SECURITY fields (PROFILE and USERID) to the values 
contained in the corresponding fields of the START_TP. 
Else 
Set TCB.INITIATING_SECURITY fields to null. 
If START_TP.REPLY equals YES then 
Create a START_TP_REPLY with a RESPONSE_CODE of OK 
and a TCB_ID equal to START_TP.TCB_ID. 
Send the START_TP_REPLY to the process that issued the 
START_TP request. 
Else 
Decrement the INSTANCE_COUNT of the TRANSACTION_PROGRAM (corresponding 
to the PS instance that 1s being destroyed) by 1. 
Destroy the TCB and destroy the PS process corresponding to TERMINATE_PS.TCB_ID. 
Destroy the TERMINATE_PS record. 
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PURGE_QUEUED_REQUESTS 


FUNCTION: 


INPUT: 


OUTPUT : 


This procedure purges Attach and START_TP requests queued for a TP-PS process 
that currently has no instances running (possibly they abended) and none can 
be created. 


TRANSACTION_PROGRAM 


Queued Attachs and related RCBs destroyed» associated sessions unbound, queued 
START_TPs destroyed, TP initiating process notified 


Referenced procedures, FSMs, and data structures: 


SM page 4-48 
START_TP_REPLY page A-20 
TRANSACTION_PROGRAM page A-5 

MU page A-29 
START_TP page A-19 
RCB page A-6 

SCB . page A-8& 

DEACTIVATE_SESSION | page A-21 
SESSION_DEACTIVATED page A-14 
SESSION_DEACTIVATED_PROC page 3-72 


If the pointer to the TRANSACTION_PROGRAM record is not null then 
Do while there are waiting initiation requests for the transaction program identified 
by TRANSACTION_PROGRAM: 
Select based on the first queued request's record type: 
When MU (MU containing Attach) 


Find the RCB identified by MU.RM_TO_PS.RCB_ID. 
Find the SCB identified by RCB.HS_ID. 
Destroy the RCB. 


Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 


containing MU (Appendix B). 
If the SCB is found then 
Create a DEACTIVATE_SESSION record initializing STATUS to ACTIVE; 
HS_ID to SCB.HS_ID, TYPE to ABNORMAL, and SENSE_CODE to X‘08640000'. 
Send the DEACTIVATE_SESSION record to SM. 
Create a SESSION_DEACTIVATED record initializing HS_ID to SCB.HS_ID> 
REASON to ABNORMAL_RETRY, and SENSE_CODE to X'08640000'. 
Call SESSION_DEACTIVATED_PROC(SESSION_DEACTIVATED) (page 3-72) 


When START_TP 


If START_TP.REPLY is YES then 
Create a START_TP_REPLY record initializing RESPONSE_CODE to 
PS_CREATION_FAILURE and TCB_ID to a null value. 
Send the START_TP_REPLY to the initiating process. 
Destroy the START_TP record. 
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QUEUE_ATTACH_PROC 


FUNCTION: For an Attach that cannot be immediately satisfied because it is to a limited 
instance TP that is currently in use, this procedure creates and initializes 
an RCB and queues the Attach request. 


INPUT : An MU containing an FMH-5 (Attach) 


OUTPUT : A newly created RCB and the MU placed on a queue waiting for a TP to become 
available | | 


Referenced procedures, FSMs, and data structures: 


FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
MU page A-29 
RCB page A-6 

SCB page A-8 


Create an RCB with a unique RCB_ID, setting the TCB_ID to null, 
the TP_NAME to the transaction program name contained in the Attach, 
HS_ID to MU.HS_TO_RM.HS_ID, BRACKET_ID to a unique value, 
SYNC_LEVEL to the sync level of the Attach 
and the HS_TO_PS_BUFFER_LIST to empty. 
If there is a conversation correlator in the Attach then 
Set the RCB.CONVERSATION_ CORRELATOR to the conversation correlator in the Attach. 
Else 
Set the RCB.CONVERSATION_CORRELATOR to null. 
Find the SCB identified by MU.HS_TO_RM.HS_ID. 
Set RCB.LU_NAME to SCB.LU_NAME and RCB.MODE_NAME to SCB.MODE_NAME. 
If the session is a first speaker then 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_FSP (page 3-90). 
Else 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_BIDDER (page 3-89). 
Call #FSM_RCB_STATUS(R», ATTACH, HS) (page 3-90). 
Set SCB.BRACKET_ID to RCB.BRACKET_ID. 
Set SCB.RCB_ID to RCB.RCB_ID. 
Set RCB.SESSION_IDENTIFIER TO SCB.SESSION_IDENTIFIER. 
Call #FSM_SCB_STATUS(R, ATTACH, UNDEFINED) (page 3-84). 
Set the MU.RM_TO_PS fields as follows: RCB_ID to RCB.RCB_ID> 
SEND_RU_SIZE to SCB.SEND_RU_ SIZE, LIMITED_BUFFER_POOL_ID to SCB.LIMITED_BUFFER_POOL_ID, 
PERMANENT_BUFFER_POOL_ID to SCB.PERMANENT_BUFFER_POOL_ID, and SENSE_CODE to X'00000000' 
(waiting Attach record has passed all RM error checks). 
Queue the Attach MU to await the freeing of an active target TP-PS instance. 
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RM_ACTIVATE_SESSION_PROC 


FUNCTION: This procedure processes the RM_ACTIVATE_SESSION record. 


An RM_ACTIVATE_SESSION record is sent to RM by PS.COPR (Chapter 5.4) when the 
control operator issues an ACTIVATE_SESSION command. The command directs RM 
to activate anew session to the partner LU identified by LU_NAME with the 
mode specified by MODE_NAME. 


RM replies to the RM_ACTIVATE_SESSION record with an RM_SESSION_ACTIVATED 
record. The RETURN_CODE field of RM_SESSION_ACTIVATED indicates the success 
or failure of the session activation. 


INPUT: RM_ACTIVATE_SESSION 
OUTPUT: ACTIVATE_SESSION to SM, or  RM_SESSION_ACTIVATED with RETURN_CODE = 


LU_MODE_SESSION_LIMIT_EXCEEDED to PS, or RM_ACTIVATE_SESSION saved as a pend- 
ing operator activation request 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
SESSION_ACTIVATION_POLARITY page 3-71 
SEND_ACTIVATE_SESSION page 3-65 
RM_ACTIVATE_SESSION page A-16 
RM_SESSION_ACTIVATED page A-22 


Call SESSION_ACTIVATION_POLARITY(RM_ACTIVATE_SESSION. LU NAME ; 
RM_ACTIVATE_SESSION.MODE_NAME) (page 3-71) 
to determine the polarity of the next activated session (1f any). 
Select based on the activation polarity: 
When NONE (session limit exceeded) 
Create an RM_SESSION_ACTIVATED record. 
Set RM_SESSION_ACTIVATED.RETURN_CODE to LU_MODE_SESSION_LIMIT_ EXCEEDED. 
Send the RM_SESSION_ACTIVATED record to PS (Chapter 5.4). 
Destroy RM_ACTIVATE_SESSION record. 
When FIRST_SPEAKER 
Call SEND_ACTIVATE_SESSION(RM_ACTIVATE_SESSION.LU_NAME 
RM_ACTIVATE_SESSION.MODE_NAME, FIRST_SPEAKER) (page 3-65). 
Save the RM_ACTIVATE_SESSION record as a pending operator activation request. 
When BIDDER 
Call SEND_ACTIVATE_SESSION(RM_ACTIVATE_SESSION.LU_NAME 
RM_ACTIVATE_SESSION.MODE_NAME, BIDDER) (page 3-65). 
Save the RM_ACTIVATE_SESSION record as a pending operator activation request. 
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RM_DEACTIVATE_SESSION_PROC 


FUNCTION: This procedure performs the processing of the RM_DEACTIVATE_SESSION record. 


An RM_DEACTIVATE_SESSION record is sent to RM by PS.COPR (Chapter 5.4) when 
the control operator issues a DEACTIVATE_SESSION command. The command directs 
RM to deactivate the session identified by HS_ID. 


INPUT : RM_DEACTIVATE_SESSION 


OUTPUT: DEACTIVATE_SESSION to SM, BIS_RQ to HS» session possibly removed from the 
free-session pool 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-68 

SEND_BIS_RQ page 3-67 

FSM_BIS_BIDDER page 3-87 

FSM_BIS_FSP page 3-88 

RM_DEACTIVATE_SESSION page A-17 . 

SCB page A-8 < 
Sa 


Find the SCB that has an HS_ID that matches the RM_DEACTIVATE_SESSION.SESSION_ID. 
If the SCB is found then | 
Select based on RM_DEACTIVATE_SESSION. TYPE: 
When CLEANUP | 
Call SEND_DEACTIVATE_SESSION( ACTIVE, RM_DEACTIVATE_SESSION.SESSION_ID, 
CLEANUP, X'00000000') (page 3-68). 
Destroy the RM_DEACTIVATE_SESSSION record. 
When NORMAL 
If the session is in use then 
If state of #FSM_BIS (page 3-87) * BIS_SENT then (BIS not already sent) 
Queue the deactivation request. ; 
Else a, 
Destroy the RM_DEACTIVATE_SESSSION record. \ 
Else (session not in use) ~~ 
Queue the deactivation request. 
Call SEND_BIS_RQ(HS_ID) (page 3-67). 
Remove the session from the free-session pool. 
Else 
Destroy the RM_DEACTIVATE_SESSION record. 
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FUNCTION: 


INPUT : 


OUTPUT: 


RTR_RQ_PROC 


This procedure handles the receipt of RTR requests froma _  first-speaker 
half-session. 


The session is returned to the free-session pool, and if there is a waiting 
request, the request is processed anda +RSP(RTR) is sent to the resources 


manager of the first-speaker half-session. If not, a -RSP(RTR, 0819) is sent 
to the resources manager to indicate that the resources manager of the bidder 
half-session has nothing to send. 


RTR_RQ from HS 


Positive RTR_RSP» or negative RTR_RSP(SENSE_CODE = X'08190000') to 


Referenced procedures, FSMs» and data structures: 


HS page 6.0-3 

GET_SESSION_PROC page 3-52 

oN SEND_DEACTIVATE_SESSION page 3-68 
C SHOULD_SEND_BIS page 3-76 
“ SEND_BIS page 3-66 
RTR_RQ page A-12 

GET_SESSION page A-16 

RTR_RSP page A-13 

SCB page A-8& 


Get addressability to the SCB representing the session on which the RTR_RQ was received. 
If SCB.RTR_OWED is TRUE (the partner LU owes an RTR) then 
If there are any GET_SESSION requests waiting for sessions with 
the partner LU and mode then 


Return the session to the free-session pool. 
ae, Create an RTR_RSP record with RTI set to POS and SENSE_CODE set to xX'00000000'. 
*s Send the RTR_RSP record to HS (Chapter 6.0). 
z Remove a GET_SESSION record from the waiting request queue. 
mae Call GET_SESSION_PROC(GET_SESSION) (page 3-52) to process the request. 


Else (no waiting requests ) 


Create 


an RTR_RSP record with RTI set to NEG and SENSE_CODE set to X'08190000'. 


Send the RTR_RSP record to HS (Chapter 6.0). 
Call SHOULD_SEND_BIS(RTR_RQ.HS_ID) (page 3-76) to determine whether 
BIS should be sent on this session. 


If BIS 


should be sent then 


Call SEND_BIS(RTR_RQ.HS_ID) (page 3-66). 


Else 


Return the session to the free-session pool. 


Else (RTR not expected) 


S Set SCB.RTR_OWED to FALSE. 


Call SEND_DEACTIVATE_SESSION( ACTIVE, RTR_RQ.HS_ID, ABNORMAL, X'20030000') (page 3-68). 
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RTR_RSP_PROC 


FUNCTION: This procedure handles the receipt of RTR responses from a _ bidder 
half-session. 


If the input is a positive RTR_RSP, no processing is performed. If the input 
is a negative RTR_RSP(SENSE_CODE = X'0819'), the session is returned to the 
free-session pool, and the session is used to service a waiting request (if 
any ). , - 


INPUT: Positive or negative RTR_RSP from HS 


OUTPUT: The session may be returned to the free-session pool. 


NOTE : If #FSM_BIS is not in the RESET state when RTR_RSP is received, this procedure 
does not return the session to the free-session pool, since the session is in 
the process of being shut down. This can occur, for example, when the first 
speaker has sent a BIS and the bidder responds negatively to a previous RTR 
before sending its own BIS. 


Referenced procedures, FSMs, and data structures: 


DEQUEUE_WAITING_REQUEST page 3-48 
SHOULD_SEND_BIS page 3-76 
SEND_BIS page 3-66 
FSM_BIS_BIDDER page 3-87 
FSM_BIS_FSP page 3-88 
RTR_RSP page A-13 


If RTR_RSP.RTI is NEG and the state of #FSM_BIS is RESET (page 3-87) then (see Note) 
Call SHOULD_SEND_BIS(RTR_RSP.HS_ID) (page 3-76) 
to determine whether BIS should be sent on this session. 
If BIS should be sent then 
Call SEND_BIS(RTR_RSP.HS_ID) (page 3-66). 
Else 
Return the session to the free-session pool. 
Call DEQUEUE_WAITING_REQUEST(RTR_RSP.HS_ID) (page 3-48) to process any waiting requests. 
Destroy the RTR_RSP record. 
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FUNCTION: This procedure checks the FMH-12, checks that the session is in the proper 


INPUT: 


OUTPUT : 


state to receive an FMH-12, and verifies the enciphered data found in the 
FMH-12. 


An MU that contains the FMH-12 (see SNA Formats) 


UNBIND processing if in error, state change of FSM_SCB_STATUS if OK, the buff- 
er used by the MU freed 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-68 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
MU page A-29 
SCB page A-8& 
LUCB page A-1 
C Find the SCB identified by MU.HS_TO_RM.HS_ID. 
: _ Remove the random data sent in the RSP(BIND) (found in SCB.RANDOM_DATA) 


from the LUCB.PENDING_RANDOM_DATA_LIST. 
If the state of #FSM_SCB_STATUS # PENDING_FMH12 (page 3-84) or 
the FMH_12 length # 10 or the enciphered random data received in the FMH-12 # 
this LU's enciphered version of the same random data then 
Call SEND_DEACTIVATE_SESSION( ACTIVE, SCB.HS_ID, ABNORMAL, X'‘'O80F6051') (page 3-68). 
Optionally log the error in the system log. 


Else 


Call #FSM_SCB_STATUS(R, FMH_12, UNDEFINED) (page 3-84) 
(initialized by CREATE_SCB). | 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer containing MU 


(Appendix B). 3 


SEND_ACTIVATE_SESSION 


FUNCTION: This procedure sends an ACTIVATE_SESSION record to the session manager’ to 


Cy INPUT: 


OUTPUT : 


request activation of a half-session. The appropriate pending session counts 
are incremented. 


LU_NAME, the name of the partner LU; MODE_NAME, the name of the mode; the ses- 
sion polarity (FIRST_SPEAKER or BIDDER) 


ACTIVATE_SESSION to SM, the pending session counts incremented 


Referenced procedures, FSMs, and data structures: 


SM page %-48 
ACTIVATE_SESSION page A-20 
PENDING ACTIVATION, see ACTIVATE_SESSION page A-20 
MODE page A-3 

LU_NAME page 3-91 
MODE_NAME page 3-91 


Find the MODE control block associated with LU_NAME and MODE_NAME. 

Create an ACTIVATE_SESSION record and set the subfields as follows: 
CORRELATOR to a unique value, LU_NAME and MODE_NAME to the LU_NAME 
and MODE_NAME inputs, and SESSION_TYPE to the session polarity input. 

Create a PENDING_ACTIVATION record initializing its subfields to the 
same values as in the ACTIVATE_SESSION fields. 

Queue the PENDING ACTIVATION. 

> Increment the MODE.PENDING_SESSION_ COUNT by 1. 

Increment the MODE.PENDING_CONWINNERS_ COUNT or MODE .PENDING_CONLOSERS_COUNT by 1; 
as appropriate to the session polarity. 

Send the ACTIVATE_SESSION record to SM (Chapter 4). 
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SEND_ATTACH_TO_PS 


SEND_ATTACH_TO_PS 


FUNCTION: This procedure fills in the RM_TO_PS header information in the MU and sends it 
to the appropriate instance of PS.CONV. 


INPUT: The MU containing the FMH-5 (Attach) and the information to be inserted in the 
MU: TCB ID, RCB ID, and error sense data 


OUTPUT: The updated MU sent to PS 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
SCB page A-8 
MU page A-29 
RCB_ID page 3-91 
TCB_ID page 3-91 


Find the SCB identified by MU.HS_TO_RM.HS_ID. 

Set the MU.RM_TO_PS fields as follows: RCB_ID to input RCB_ID, TCB_ID to input TCB_ID 
SEND_RU_SIZE to SCB.SEND_RU_SIZE, LIMITED_BUFFER_POOL_ID to SCB.LIMITED_BUFFER_POOL_ID, 
PERMANENT_BUFFER_POOL_ID to SCB.PERMANENT_BUFFER_POOL_ID, 
and SENSE_CODE to the input sense data. 

Send the MU to PS (Chapter 5.0). 

If the send fails then 

Call buffer manager (FREE_BUFFER, buffer address) to release the buffer containing MU 
(Appendix B). 
Optionally log the error in the system log. 


SEND_BIS 


FUNCTION: This procedure causes either BIS_RQ or BIS_REPLY to be sent on the session 
identified by HS_ID. The choice of BIS_RQ or BIS_REPLY is dependent on the 
state of #FSM_BIS. 7 


_ 


INPUT: HS_ID, the ID of the session 


OUTPUT: BIS_RQ or BIS_REPLY to HS 


Referenced procedures, FSMs, and data structures: 


SEND_BIS_RQ page 3-67 
SEND_BIS_REPLY page 3-67 
FSM_BIS_BIDDER page 3-87 
FSM_BIS_FSP page 3-88 
HS_ID page 3-91 


Select based on the state of #FSM_BIS (page 3-87): 
When RESET 
Call SEND_BIS_RQ(HS_ID) (page 3-67). 
When BIS_RCVD 
Call SEND_BIS_REPLY(HS_ID) (page 3-67). 
Otherwise 
Do nothing. 
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SEND_BIS_REPLY 


SEND_BIS_REPLY 


FUNCTION: This procedure creates a BIS_REPLY and sends it to HS. 


INPUT: HS_ID, the ID of the half-session over which the BIS_REPLY will flow 


- QUTPUT: BIS REPLY sent to HS, MODE termination count incremented 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_BIS_BIDDER page 3-87 
FSM_BIS_FSP page 3-88 
BIS REPLY page A-12 
MODE page A-3 
HS_ID page 3-91 


Call #FSM_BIS(S, BIS_REPLY, HS_ID) (page 3-87) for the session 
identified by HS_ID. 


Poa Create a BIS_REPLY record and send it to HS (Chapter 6.0). 
< Get addressability to the MODE control block associated with the LU and mode 
=A name of the session identified by HS_ID. 


Increment MODE .PENDING_TERMINATION_CONWINNERS or MODE.PENDING_TERMINATION_CONLOSERS by l, 
as appropriate to the session polarity. 


SEND_BIS_RQ 


C FUNCTION: This procedure creates a BIS_RQ and sends it to HS. 
} 
a After the BIS_RQ is sent to the half-session, the appropriate pending termi- 
nation count is incremented. 
INPUT : HS_ID, the ID of the half-session over which the BIS_RQ will flow 
OUTPUT: BIS RQ to HS, pending termination counts adjusted, queued 
RM_DEACTIVATE_SESSION records possibly destroyed 
NOTE : The TERMINATION_COUNT is not decremented if the BIS_RQ was sent as a result of 
a control operator RM_DEACTIVATE_SESSION request. 
€ Referenced procedures, FSMs, and data structures: 
HS page 6.0-3 
FSM_BIS_BIDDER page 3-87 
FSM_BIS_FSP page 3-88 
BIS_RQ page A-12 
MODE page A-3 
RM_DEACTIVATE_SESSION page A-17 
HS_ID | page 3-91 


Create a BIS_RQ record and send it to HS (Chapter 6.0). 
Call #FSM_BIS(S, BIS_RQ, HS_ID) (page 3-87) for the session identified by HS_ID. 
Get addressability to the MODE control block associated with the LU and mode 
name of the session identified by HS_ID. 
Increment MODE .PENDING_TERMINATION_CONWINNERS or MODE.PENDING_TERMINATION_CONLOSERS by 1, 
as appropriate to the session polarity. 
If there is a queued (pending) CNOS operator session deactivation request for the session 
identified by HS_ID then 
Discard all queued RM_DEACTIVATE_SESSION requests for the session identified by HS_ID. 
Else (see Note) 
Decrement MODE.TERMINATION_COUNT by 1. 
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SEND_DEACTIVATE_SESSION 


3-68 


SEND_DEACTIVATE_SESSION 


FUNCTION: This procedure sends a DEACTIVATE_SESSION record to SM. 


If the STATUS is PENDING, the appropriate pending-session counts are decre- 
mented. If STATUS is ACTIVE, a SESSION_DEACTIVATED record is created and SES- 
SION_DEACTIVATED_PROC is called to continue’ processing the session 
deactivation. SM does not send SESSION_DEACTIVATED in reply to DEACTI- 
VATE_SESSION. Thus, the SESSIONS DEACTIVATED is created in this procedure and 


SESSION_DEACTIVATED_PROC is called to perform common processing. 


STATUS (ACTIVE or PENDING), CORRELATOR (HS_ID if STATUS = ACTIVE, else 
correlator used on ACTIVATE_SESSION request), TYPE (NORMAL, CLEANUP, ABNOR- 
MAL), and SENSE_CODE (X'00000000' if TYPE = NORMAL) 


OUTPUT : DEACTIVATE_SESSION to SM, MODE pending counts adjusted, waiting activation 
requests destroyed, waiting GET_SESSION requests rejected and destroyed, SES- 
SION_DEACTIVATED records created 


Referenced procedures, FSMs, and data structures: \ 


SESSION_DEACTIVATED_PROC ~ page 3-72 Se 
PS page 5.0-8 
SM page 4-48 
SENSE_CODE page 3-92 
MODE page A-3 
GET_SESSION page A-16 
PENDING_ACTIVATION, see ACTIVATE_SESSION page A-20 
DEACTIVATE_ SESSION page A-21 
SCB page A-8 
SESSION_DEACTIVATED page A-14 
SESSION_ALLOCATED page A-22 

Select based on the value of session status: —_— 


When PENDING \ 
If there is a PENDING ACTIVATION record with a matching CORRELATOR then oe 
(the pending activation is Known to RM) 

Create a DEACTIVATE_SESSION record with DEACTIVATE_SESSION.STATUS set to PENDING, 
DEACTIVATE_SESSION.CORRELATOR set to CORRELATOR, 
DEACTIVATE_SESSION.TYPE set to TYPE, and 
DEACTIVATE_SESSION.SENSE_CODE set to SENSE_CODE. 

Send the DEACTIVATE_SESSION record to SM (Chapter 4). 

Get addressability to the MODE control block associated with the LU 
and mode name of the pending active session. 

Decrement MODE .PENDING_CONWINNERS_COUNT or MODE.PENDING_CONLOSERS COUNT by 1l> 


as appropriate to the session polarity. Ps 
Decrement MODE.PENDING_SESSION_COUNT by 1. ( 
Destroy the PENDING_ACTIVATION record. No 


If MODE .ACTIVE_SESSION_COUNT + MODE.PENDING_SESSION_COUNT = 0 then 
Do for each GET_SESSION request waiting for a session to this LU name for this 
mode name: 
Create a SESSION_ALLOCATED record with RETURN_CODE set to 
UNSUCCESSFUL_NO_RETRY and send it to the PS (Chapter 5.1) 
that initiated the session request. 
Destroy the waiting GET_SESSION record. 
When ACTIVE 
If there exists an SCB where SCB.HS_ID = CORRELATOR then (session is Known to RM) 
Create a DEACTIVATE_SESSION record with DEACTIVATE_SESSION.STATUS set to ACTIVE, 
DEACTIVATE_SESSION.HS_ID set to CORRELATOR, 
DEACTIVATE_SESSION.TYPE set to TYPE, and 
DEACTIVATE_SESSION.SENSE_CODE set to SENSE_CODE. 
Send the DEACTIVATE_SESSION to SM (Chapter 4). 
Create a SESSION_DEACTIVATED record with HS_ID set to CORRELATOR. 
If TYPE is NORMAL then 
Set SESSION _DEACTIVATED.REASON to NORMAL. 
Else 
Set SESSION _DEACTIVATED.REASON to ABNORMAL_NO_RETRY. 
Set SESSION _DEACTIVATED.SENSE_CODE to SENSE_CODE. eee 
Call SESSION_DEACTIVATED_PROC(SESSION_DEACTIVATED) (page 3-72). q 
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SEND_RTR_PROC 
SEND_RTR_PROC 


FUNCTION: This procedure handles the processing that occurs when a SEND_RTR is received 
by RM. 


INPUT: SEND_RTR 


OUTPUT: RTR request sent on the session identified by the SEND_RTR record and the free 


session is removed from the free-session pool; or (if SEND_RTR is in error) a 
log entry is made; SEND_RTR record destroyed 


The session is not free if it is in use. After the use of the session, a 
FREE_SESSION record will be received by RM and the logic to send RTR will 
again be exercised (see FREE_SESSION_PROC on page 3-50). When the session is 
in use, the SEND_RTR is ignored and discarded. 


Referenced procedures, FSMs, and data structures: 


SCB page A-8& 
—_ RTR_RQ page A-12 
oo SEND_RTR page A-~20 


Find the SCB identified by SEND_RTR.HS_ID. 

If the SCB exists and the session it represents is free and first speaker then 
Create and send an RTR_RQ to the associated half-session process. 
Set SCB.RTR_OWED to FALSE. 
Remove the session from the free-session pool. 

Destroy the SEND_RTR record. 
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SESSION_ACTIVATED_ALLOCATION 


SESSION_ACTIVATED_ALLOCATION 


FUNCTION: This procedure handles the allocation processing for a newly activated 
first-speaker or bidder half-session. 


This procedure causes the SCB associated with the half-session and the RCB of 
a conversation for which a session was requested to point to each other. It 
then creates a SESSION_ALLOCATED record, which it sends to PS to inform it 
that the session has been allocated. 


INPUT: GET_SESSION and HS_ID, the ID of the new half-session 


OUTPUT: SESSION_ALLOCATED to PS and destruction of the GET_SESSION 


Referenced procedures, FSMs, and data structures: 


SET_RCB_AND_SCB_FIELDS page 3-75 
CONNECT_RCB_AND_SCB page 3-42 

PS page 5.0-8 
FSM_RCB_STATUS_FSP . page 3-90 i 
FSM_RCB_STATUS_BIDDER page 3-89 | 
GET_SESSION page A-16 eee 
HS_ID page 3-91 
SESSION_ALLOCATED page A-22 

SCB page A-8 


If the session identified by HS_ID is a bidder session then 
For the conversation identified by GET_SESSION.RCB_ID, 
Call #FSM_RCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-89). 
Call SET_RCB_AND_SCB_FIELDS(GET_SESSION.RCB_ID, HS_ID) (page 3-75). 
Call CONNECT_RCB_AND SCB(GET_SESSION.RCB_ID, HS_ID, NORMAL) (page 3-42). 
Find the SCB identified by HS_ID 
Create a SESSION_ALLOCATED record with RETURN_CODE set to OK, 


SEND_RU_SIZE set to SCB.SEND_RU_SIZE, - 
LIMITED_BUFFER_POOL_ID set to SCB.LIMITED_BUFFER_POOL_ID, oe 
PERMANENT_BUFFER_POOL_ID set to SCB.PERMANENT_BUFFER_POOL_ID, od 


IN_CONVERSATION set to 'YES', 
and send the record to PS (Chapter 5.1). 


SESSION_ACTIVATED_PROC 


FUNCTION: This procedure performs the processing of a SESSION_ACTIVATED record from SM. 
SESSION_ACTIVATED is received from SM as a result of session activation initi- 
ated by the partner LU. 


INPUT : SESSION_ACTIVATED from SM 


OUTPUT : Active session counts incremented 


Referenced procedures, FSMs», and data structures: 


SUCCESSFUL_SESSION_ACTIVATION page 3-80 
SESSION_ACTIVATED page A-14¢ 
MODE page A-3 


Get addressability to the MODE control block associated with the LU and 

mode name of the newly activated session. 

Increment MODE.ACTIVE_CONWINNERS_COUNT or MODE.ACTIVE_CONLOSERS_COUNT by 1), 

as appropriate to the session polarity. 

Increment MODE.ACTIVE_SESSION_COUNT by l. 

Call SUCCESSFUL_SESSION_ACTIVATION( SESSION_ACTIVATED.LU_NAME 5 

SESSION_ACTIVATED.MODE_NAME, SESSION_ACTIVATED.SESSION_INFORMATION) (page 3-80). oa 
Destroy the SESSION_ACTIVATED record. q 
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SESSION_ACTIVATIGN_POLARITY 


FUNCTION: This procedure determines the polarity for a session activation request. 


If no session can be activated now (because MODE.SESSION_LIMIT would be 
exceeded), NONE is returned. If either a first-speaker or bidder session 
could be activated, FIRST_SPEAKER is returned. Thus, first-speaker sessions 
are activated in preference to bidder sessions. 


INPUT: LU_NAME, the name of the LU to which a session is to be activated; and 
MODE_NAME, the name of the mode 
OUTPUT: NONE, if no session can be activated; FIRST_SPEAKER, if a first-speaker ses- 
| sion can be activated; BIDDER, otherwise 
CO Referenced procedures, FSMs, and data structures: 

PARTNER_LU page A-2 
LU_NAME page 3-91 
MODE_NAME page 3-91 
MODE page A-3 


Get addressability to the PARTNER_LU control block associated with LU_NAME. 
Get addressability to the MODE control block associated with LU_NAME and MODE_NAME. 
If the number of pending and active sessions for the MODE 
1s 2 MODE.SESSION_LIMIT then 
Return with an indication that no additional sessions can be activated. 
If the total number of pending and active sessions for the MODE 
‘ is > 0 and PARTNER_LU.PARALLEL_SESSION is SUPPORTED then 
J Return with an indication that no additional sessions can be activated. 
a If MODE.SESSION_LIMIT - MODE.MIN_CONLOSERS_LIMIT > 
MODE .ACTIVE_CONWINNERS_COUNT + MODE.PENDING_CONWINNERS COUNT then 
Return with an indication that a first-speaker session can be activated. 
Else 
Return with an indication that a bidder session can be activated. 
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SESSION_DEACTIVATED_PROC 


FUNCTION: This procedure handles the processing that occurs when a session is deacti- 
vated. 


When SESSION_DEACTIVATED.REASON = NORMAL and the session was not being used by 
a conversation, no processing (except destruction of the SCB) takes place, 
since the decision to close down a_ session was mutually reached by the 
resources managers of the half-sessions via BIS protocols, and all necessary 
processing has already been performed. 


When SESSION_DEACTIVATED.REASON = NORMAL, ABNORMAL_RETRY, or ABNORMAL_NO_RETRY 
and the session was being used by a conversation, this procedure sends a CON- 
VERSATION_FAILURE record to PS. If the session was not in use, the session is 
removed from the free-session pool. Regardless of whether the session was in 
use, this procedure deletes the SCB entry for that half-session. 


INPUT: SESSION_DEACTIVATED 


OUTPUT : CONVERSATION_FAILURE to PS, destruction of the SCB; a queued Attach may be 
purged; the active contention-winner, contention-loser, and session counts are 
adjusted; pending termination counts are adjusted; sessions are activated; if 
they cannot be satisfied, waiting requests are rejected; the session deacti- 
vated TP may be started; the SESSION_DEACTIVATED record 1is_ destroyed; 
RM_ACTIVATE_SESSION records are rejected using RM_SESSION_ACTIVATED records. 


When PS receives a CONVERSATION_FAILURE, it generates a DEALLOCATE_RCB and 
sends it to RM, which performs the usual RCB deallocation processing. 


An UNBIND type Normal not preceded by BIS protocols can occur when an SSCP has 
issued a CTERM type Forced to an LU. Under any other circumstance, an UNBIND 
type Normal not preceded by BIS protocols is a protocol violation. 


It is possible for two RCBs to be associated with the same SCB when SON 
occurs. This happens when RM has issued a Bid for the use of a_ bidder 
half-session and, prior to receiving the response to the Bid, subsequently 
receives an Attach from the first-speaker side of the session. When RM 
receives the session-outage notification, it notifies the PS that was created 
as a result of the incoming Attach that a conversation failure has occurred. 
The PS associated with the RCB that is pending a response to the Bid, however, 
never learns of the session outage. RM treats the SON as a_ -BID_RSP and 
attempts to satisfy the session request with another session. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 a, 
GET_SESSION_PROC . page 3-52 | 
ACTIVATE_NEEDED_ SESSIONS page 3-24 ue 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-39 
SESSION_ALLOCATED | page A-22 

MU page A-29 
SESSION_DEACTIVATED page A-14¢ 
CONVERSATION_FAILURE page A-21 

GET_SESSION page A-16 
RM_ACTIVATE_SESSION page A-16 
RM_SESSION_ACTIVATED page A-22 

SCB page A-8 

RCB -page A-6 

MODE page A-3 

PARTNER_LU page A-2 


C) 
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SESSION_DEACTIVATED_PROC 


If an SCB associated with the half-session identified by 
ak SESSION_DEACTIVATED.HS_ID exists then 
C Get addressability to the MODE control block associated with the LU name and 
‘ mode name of the deactivated session. 
If the state of #FSM_SCB_STATUS (page 3-84) is IN_USE then 
If the RCB identified by the SCB.RCB_ID exists then 
If the RCB.TCB_ID is not null (in conversation) then 
Create a CONVERSATION FAILURE record with RCB_ID set to SCB.RCB_ID. 
Select based on SESSION_DEACTIVATED.REASON: 
When NORMAL 
Set CONVERSATION_FAILURE.REASON to SON. (Note 2) 
When ABNORMAL_RETRY 
Set CONVERSATION_FAILURE.REASON to SON. 
When ABNORMAL_NO_RETRY 
Set CONVERSATION_FAILURE.REASON to PROTOCOL_VIOLATION. 
Send the CONVERSATION_FAILURE record to the PS process that was 
using the deactivated session. 
Else (MU containing an Attach from the ended HS is queued awaiting a TP) 
Find the MU queued for the transaction program identified by RCB.TP_NAME 
and where MU.RM_TO_PS.RCB_ID = RCB.RCB_ID. 
Destroy the RCB. 
ae Remove the MU from the queue. 
e Call buffer manager (FREE_BUFFER, buffer address} to release the buffer 
a“ containing MU (Appendix B). 
Else (session not in use by a conversation) 
Remove the session from the free-session pool. 
If there is an RCB where RCB.HS_ID = SESSION _DEACTIVATED.HS_ID and 
the state of #FSM_RCB_STATUS = PENDING_SCB (page 3-89) then 
(A bid for the deactivated session is in progress; see Note 3). 
Set RCB.HS_ID to a null value. 
Call #FSM_RCB_STATUS(R, NEG_BID_RSP, UNDEFINED) (page 3-89). 
Create a GET_SESSION record from information saved in the RCB. (see BIDDER_PROC) 
Call GET_SESSION_PROC(GET_SESSION) (page 3-52) 
to retry the bid on another session. 
Decrement MODE .ACTIVE_CONWINNERS COUNT or MODE.ACTIVE_CONLOSERS COUNT by 1, 
a. as appropriate to the session polarity. 
- Decrement MODE .ACTIVE_SESSION_COUNT by 1. 
If there is a pending deactivation for the failed session then 
Decrement MODE .PENDING_TERMINATION_CONWINNERS or MODE.PENDING_TERMINATION_CONLOSERS 
by 1, as appropriate to the session polarity. 
If SESSION_DEACTIVATED.REASON * ABNORMAL_NO_RETRY then 
Call ACTIVATE_NEEDED_SESSIONS(SCB.LU_NAME, SCB.MODE_NAME) (page 3-24). 
If MODE.ACTIVE_SESSION_COUNT + MODE.PENDING_SESSION_COUNT = 0 then 
If the PARTNER_LU for the failed session does not support parallel sessions 
the SESSION_DEACTIVATED.REASON is not ABNORMAL_NO_RETRY then 
If there is a waiting request on another mode 
CALL ACTIVATE_NEEDED_SESSIONS( PARTNER_LU.LOCAL_LU_NAME ,MODE .NAME ) 


perks, Do for each GET_SESSION request waiting for a session to (LU_NAME, MODE_NAME ): 
f Create a SESSION_ALLOCATED record with RETURN_CODE set to UNSUCCESSFUL_NO_RETRY 
a. and send it to the PS (Chapter 5.1) that initiated the session request. 


Destroy the waiting GET_SESSION request. 
Do for each pending RM_ACTIVATE_SESSION request for a session to 
(LU_NAME , MODE_NAME ): 
Create RM_SESSION_ ACTIVATED with RETURN_CODE set to ACTIVATION_FAILURE_NO_RETRY 
and send it to the PS (Chapter 5.1) that initiated the activation request. 
Destroy the RM_ACTIVATE_SESSION request. 
Destroy the SCB. 
Destroy the SESSION_DEACTIVATED record. 


a 
{ 
/ 
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SESSION_DEACTIVATION_POLARITY 


FUNCTION: This procedure determines the polarity of a session to partner LU (LU_NAME; 
MODE_NAME) that this LU is responsible for deactivating. 


INPUT : LU_NAME, the name of the partner LU; and MODE_NAME, the name of the mode 


OUTPUT: One of the following indications to the caller: NONE, if this LU is not 
responsible for any deactivations; BIDDER, if this LU is responsible to deac- 
tivate a bidder session only; FIRST_SPEAKER, if this LU is responsible to 
deactivate a first speaker session only; EITHER, if this LU is responsible to 
deactivate either a first speaker or bidder session. The TERMINATION_COUNT is 
reset to 0 1f it was positive and this LU is not responsible for any deacti- 
vations. | 


Referenced procedures, FSMs, and data structures: 
LU_NAME page 3-91 


MODE_NAME page 3-91 
MODE page A-3 jo 
Get addressability to the MODE control block associated with LU_NAME and MODE_NAME . Gu 


If MODE.TERMINATION_COUNT is 0 then 
Return with an indication that no sessions need to be deactivated. 
Let CONWINNER_COUNT be MODE .ACTIVE_CONWINNERS_COUNT + MODE.PENDING_CONWINNERS COUNT - 
MODE .PENDING_TERMINATION_CONWINNERS. 
Let CONLOSER_COUNT be MODE .ACTIVE_CONLOSERS_COUNT + MODE.PENDING_CONLOSERS COUNT - 
MODE . PENDING_TERMINATION_CONLOSERS. 
Select based on the following conditions: 
When CONWINNER_COUNT <= MODE .MIN_CONWINNERS LIMIT, and 
CONLOSER_COUNT <= MODE .MIN_CONLOSERS_ LIMIT 
Set MODE.TERMINATION_COUNT to 0. 
Return with an indication (NONE) that no sessions need to be deactivated. 
When CONWINNER_COUNT <= MODE.MIN_CONWINNERS_ LIMIT, and . . 
CONLOSER_COUNT > MODE .MIN_CONLOSERS_LIMIT - 
Return with an indication (BIDDER) that a bidder session needs to be deactivated. ~~ 
When CONWINNER_COUNT > MODE.MIN_CONWINNERS_LIMIT, and 
CONLOSER_COUNT <= MODE .MIN_CONLOSERS_ LIMIT 
Return with an indication (FIRST_SPEAKER) that a first-speaker session needs 
to be deactivated. 
When CONWINNER_COUNT > MODE.MIN_CONWINNERS LIMIT, and 
CONLOSER_COUNT > MODE .MIN_CONLOSERS_LIMIT 
Return with an indication (EITHER) that a session of either polarity needs 
to be deactivated. 
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SET_RCB_AND_SCB_FIELDS 


SET_RCB_AND_SCB_FIELDS 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTE : 


This procedure initializes fields in the RCB and SCB entries having the passed 
RCB and HS IDs. 


The RCB is set to point to the associated SCB (by placing the HS_ID in the 
RCB), and the SCB to point to the RCB (by placing the RCB_ID in the SCB). The 
FSMs that maintain the status of the RCB and SCB are set to the IN_USE state. 


RCB_ID and HS_ID, the IDs of the RCB and SCB, respectively, for which fields 
are to be set 


Fields in the RCB and SCB initialized. 


When this procedure is called from BID_RSP_PROC, RCB.HS_ID has already been 
initialized. (It was initialized when the BID record for the session was gen- 
erated.) Rather than test for this condition, the field is reset to the same 
value. 


Referenced procedures, FSMs» and data structures: 


FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
FSM_RCB_STATUS_FSP page 3-90 
FSM_RCB_STATUS_BIDDER page 3-89 
RCB_ID page 3-91 
HS_ID page 3-91 
SCB page A-8& 

RCB page A-6 


Find the SCB associated with the half-session identified by HS_ID. 

Set SCB.RCB_ID to RCB_ID. 

Find the RCB associated with the conversation identified by RCB_ID. 

Set RCB.HS_ID to HS_ID (see Note). 

If the session identified by HS_ID is a first-speaker session then 
Call #FSM_SCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-84). 
Call #FSM_RCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-89). 

Else (bidder session) 

Call #FSM_SCB_STATUS(R, POS_BID_RSP», UNDEFINED) (page 3-84). 
Call #FSM°RCB STATUS(R, POS BID _RSP, UNDEFINED) (page 3-89). 
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SHOULD_SEND_BIS 


FUNCTION: This procedure determines whether a BIS (either BIS_RQ or BIS_REPLY) should be 
sent on the session identified by HS_ID. 


INPUT: HS_ID, containing the ID of the session 


OUTPUT: TRUE, if BIS (BIS_RQ or BIS_REPLY) should be sent now; else FALSE 


NOTE : BIS is sent if there are no waiting requests for a session for this mode 


Referenced procedures, FSMs, and data structures: 


SESSION_DEACTIVATION_POLARITY | page 3-74 

FSM_BIS_ BIDDER page 3-87 

FSM_BIS_FSP page 3-88 

HS _ID page 3-91 

LU_NAME page 3-91 

MODE_NAME page 3-91 

MODE page A-3 errs 
PARTNER_LU page A-2 ( 
RM_DEACTIVATE_SESSION page A-17 ae 


Find the PARTNER_LU and MODE control block associated with 
the half-session identified by HS_ID. 
If there are no waiting requests for a session for this MODE and 
PARTNER_LU.PARALLEL_SESSIONS is NOT_SUPPORTED then 
If there is a waiting request for another mode with this partner LU then 
Return to the calling routine with the value TRUE (BIS should be sent). 
SELECT based on the state of #FSM_BIS (page 3-87): 
When RESET . 
Call SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-74) 
to determine the type of session (if any) to deactivate. = 
If the deactivation polarity is EITHER,» or «. 
the deactivation polarity matches the session polarity then 


If MODE.DRAIN_SELF is NO or there are no waiting requests for a 
sessions to this LU and mode name (See Note) then 
Return to the calling routine with the value TRUE (BIS should be sent). 
If there is a pending RM_DEACTIVATE_SESSION request for this session then 
Return to the calling routine with the value TRUE (BIS should be sent). 
Return to the calling routine with the value FALSE (BIS should not be sent). 
When BIS_RCVD | 
If MODE.DRAIN_SELF = NO or there are no waiting requests for sessions 
for this LU name and mode name (See Note) then 
Return to the calling routine with the value TRUE (BIS should be sent). 
Else | 
Return to the calling routine with the value FALSE (BIS should not be sent). : 
When BIS_SENT (BIS already sent) | a 


Return to the calling routine with the value FALSE (BIS should not be sent). 
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START_TP_PROC 


FUNCTION: 
INPUT : 


OUTPUT: 


Referenced pr 
PS 
STAR 
TRAN 
LUCB 
RESP 
STAR 
CREA 
STAR 
PURG 


START_TP_PROC 


This procedure performs the processing of a received START_TP record. 
START_TP request record 


A reply (RESPONSE_CODE) to the START_TP and if the request can be satisfied, 
the START_TP updated and sent to the new PS process, or queued awaiting a 
freed instance 


A null network ID in the Fully Qualified LU Name field is invalid unless this 
LU's network ID is also null. Procedures that are able to send START_TP 


records to RM are considered privileged, protected processes with code content 
integrity. These procedures may supply the fully-qualified 
(network-qualified) LU name of the requester or an Already-Verified indication 
for security (1.e., a user ID indicated as already verified, eliminating the 
need for a password). 


This logic requires support of the limited-instance transaction program option 
and requires that all transaction programs are able to perform as a 
limited-instance TP (1.e., able to accept an Attach or a START_TP after send- 
ing TERMINATE_PS). If either of these assumptions is not true, the logic in 
the Else section is performed. 


ocedures, FSMs, and data structures: 


page 5.0-8 
T_TP page A-19 
SACTION_PROGRAM page A-5 

page A-1 
ONSE_CODE page 3-92 
T_TP_REPLY page A-20 
TE_TCB_AND_PS page 3-45 
T_TP_SECURITY_VALID page 3-79 
E_QUEUED_REQUESTS page 3-59 


Set RESPONSE_CODE to OK. 
Find the TRANSACTION_PROGRAM corresponding to the START_TP.TARGET_TP_NAME. 


If the TRANSA 


CTION_PROGRAM cannot be found then 


Set RESPONSE_CODE to TPN_NOT_RECOGNIZED. 


Else 
If the TRA 
Set RES 
If the TRA 
Set RES 
If the TRA 
If the 
TRANSA 
If t 
S 
Else 
Ss 
If the RES 


NSACTION_PROGRAM.STATUS is DISABLED_TEMPORARY then 

PONSE_CODE to TRANS_PGM_NOT_AVAILABLE_RETRY. 
NSACTION_PROGRAM.STATUS is DISABLED_PERMANENT then 

PONSE_CODE to TRANS _PGM_NOT_AVAIL_NO_RETRY. 
NSACTION_PROGRAM.VERIFY_PIP is YES and RESPONSE_CODE is OK then 
number of PIP subfields in the START_TP is not equal to 
CTION_PROGRAM.NUMBER_OF_PIP_SUBFIELDS then 

he TRANSACTION_PROGRAM.NUMBER_OF_PIP_SUBFIELDS is 0 then 

et RESPONSE CODE to PIP_NOT_ALLOWED. 


et RESPONSE_CODE to PIP_NOT SPECIFIED CORRECTLY. 
PONSE_CODE is OK then 


Call START_TP_SECURITY_VALID(START_TP, TRANSACTION_PROGRAM) (page 3-79). 


If STAR 
securl 

Set 

If the RES 


T_TP_SECURITY_VALID returns indicating that 

ty requirements are not met then 

RESPONSE_CODE to SECURITY_NOT_VALID. 

PONSE_CODE is OK and a network-qualified LU name is present in START_TP 


and the network-qualified LU name does not have the proper format (see SNA Formats for 
the correct format) then 
Set RESPONSE_CODE to INVALID_FULLY_QUALIFIED_LU_NAME. 
If the RESPONSE CODE is OK then 
If a network-qualified LU name is not present in the START_TP (Note 1) then 


Set STA 


RT_TP.FULLY_QUALIFIED_LU_NAME to LUCB.FULLY_QUALIFIED_LU_NAME. 
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If TRANSACTION_PROGRAM.INSTANCE_COUNT is less than TRANSACTION_PROGRAM.INSTANCE_LIMIT then 
Call CREATE_TCB_AND_PS(START_TP, TRANSACTION_PROGRAM) (page 3-45). ~ 
If START_TP.TCB_ID is a non-null value (PS is successfully created) then | 
Send a copy of the START_TP record to PS. Sa 
If START_TP.REPLY is YES then 
Create a START_TP_REPLY record, initializing START_TP_REPLY.RESPONSE_CODE to 
RESPONSE_CODE. | 
If RESPONSE_CODE is equal to OK then 
Set the START_TP_REPLY.TCB_ID to START_TP.TCB_ID. 
Send the START_TP_REPLY record to the initiating process. 
Destroy the START_TP record. 
Else 
If TRANSACTION_PROGRAM.INSTANCE_COUNT is greater than 0 (Note 2) then 


Queue the START_TP to await the freeing of an active target TP-PS instance. 
Else 


If START_TP.REPLY is YES then 
Create a START_TP_REPLY record. 
Set the START_TP_REPLY.RESPONSE_CODE to PS_CREATION_FAILURE. 
Send the START_TP_REPLY record to the initiating process. 
Destroy the START_TP record. 
Purge any queued START_TP or Attach records for this transaction program . 
by calling PURGE_QUEUED_REQUESTS( TRANSACTION_PROGRAM) (page 3-59). 


a 
Else ( 
Queue the START_TP to await the freeing of an active target TP-PS instance. Sud) 
Else (RESPONSE_CODE is not OK) 


If START_TP.REPLY is YES then 


Create a START_TP_REPLY record, initializing START_TP_REPLY.RESPONSE_CODE to 
RESPONSE_CODE. 


Set the START_TP_REPLY.TCB_ID to a null value. 


Send the START_TP_REPLY record to the initiating process. 
Destroy the START_TP record. . 
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START_TP_SECURITY_VALID 
START_TP_SECURITY_VALID 


FUNCTION: This procedure performs all security checks on an incoming START_TP. 


INPUT: The START_TP record containing security fields (e.g.» user ID, password, and 


profile) and the pointer to the control block of the transaction program that 
the START_TP targets 


OUTPUT: An indication as to the validity of the security tokens on the START_TP: TRUE 
indicates they are valid; FALSE, invalid 


Referenced procedures, FSMs, and data structures: 
START_TP page A-19 


If START_TP.SECURITY_SELECT = NONE then 
If the transaction program requires security parameters then 
Return FALSE (security check failed). 
Else 
Return TRUE (security check passed). 
If the START_TP contains a profile but does not contain a user ID then 
Return FALSE. | 
If the START_TP contains a password but does not contain a user ID then 
Return FALSE. 
If START_TP.SECURITY_SELECT is PGM then 
If the START_TP contains a user ID but does not contain a password then 
Return FALSE. 
If the START_TP does not contain a user ID or a password and 
the transaction program requires security parameters then 
Return FALSE. | 
If the transaction program does not require security parameters and 
the START_TP does not contain a user ID or a password then 
Return TRUE. 
If the START_TP contains an unauthorized combination of user ID and profile or 
the START_TP contains an invalid combination of user ID and password then 
Return FALSE. 
Else (SECURITY_SELECT is ALREADY_VERIFIED ) 
If the START_TP does not contain a user ID or does contain a password then 
Return FALSE (Already verified indication requires a user ID and precludes a password). 
If there is limited access to the target transaction program (The access authorization is 
based upon the definition of the transaction program's access requirements and the START_TP 
record's user ID and/or profile and/or LU name of the origin of the START_TP) then 
If the user ID and/or profile and/or LU name is permitted access to the requested 
transaction program then 
Return TRUE. 
Else 
Return FALSE. 
Return TRUE. 
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SUCCESSFUL_SESSION_ACTIVATION 


FUNCTION: 


INPUT : 


OUTPUT : 


NOTE : 


This procedure handles the processing that occurs when a new session is suc- 
cessfully activated. | | 


When a new session is successfully activated, RM informs the new half-session 
that RM is aware of its existence and ready to accept records from the new 
half-session. A new session comes up "in-conversation" with the primary side 
of the session in control of the conversation. This procedure checks to see 
whether the new half-session is primary or secondary. If the half-session is 
primary and a request 1s waiting, the support levels (1.e., sync level and 
conversation-level security) specified in the request are checked against the 
support levels of the session. If the support levels are compatible, and 
LU-LU verification (session-level security) is active, the FMH-12 to complete 
LU-LU verification is built and sent to the partner-LU resources manager; then 
the request is sent to SESSION_ACTIVATED_ALLOCATION (page 3-70) to be proc- 
essed. If the support levels are not compatible, the request is rejected with 
an ALLOCATION_ERROR return code. If no requests are waiting, the session is 
returned to the free-session pool. If no request is waiting and LU-LU verifi- 
cation (session-level security) 1s active, the FMH-12 is built and sent to the 
partner-LU resources manager, and this FMH-12 relinquishes control of the ses- 
sion; otherwise, a YIELD_SESSION record is created and sent to HS to inform 
the secondary half-session that the primary is relinquishing control of the 
conversation. The YIELD_SESSION record is translated into a’ FREE_SESSION 
record by the secondary half-session and sent to its RM. 


If the new half-session is a secondary half-session and LU-LU verification is 
active, the FSM that maintains the status of the SCB is set to indicate that 
the next record it expects to receive is an FMH-12 (Security). If the new 
half-session is a secondary half-session and LU-LU verification is not active, 
the FSM that maintains the status of the SCB is set to indicate that the next 
record it expects to receive is either an Attach or a FREE_SESSION. (It will 
receive an Attach if the primary half-session decides to use the session; it 
will receive a FREE_SESSION if the primary has no GET_SESSION requests waiting 
to be serviced). 


LU_NAME and MODE_NAME, the LU name and mode name of the newly activated ses- 
sion; and SESSION_INFORMATION (page A-32), which describes the attributes of 
the activated session 


GET_SESSION to SESSION_ACTIVATED_ALLOCATION (page 3-70), YIELD_SESSION to HS; 
SESSION_ALLOCATED to PS, waiting GET_SESSION'- records destroyed, an 
RM_SESSION_ACTIVATED record possibly created to respond to a CNOS 
RM_ACTIVATE_SESSION record that will be  dequeued = from the PEND- 
ING_CNOS ACTIVATION_LIST and destroyed 


PS stores information in the RCB that tells HS what bit settings to use when 
HS sends data out over a link. Part of the information indicates whether the 
data being sent to HS is the beginning of a conversation or part of an exist- 
ing conversation. Since a new session comes up  in-conversation (a_ fact 
unknown by PS), RM changes the information in the RCB to indicate to HS that 
the next record it receives from PS will not be the start of a conversation. 


Referenced procedures, FSMs, and data structures: 


CREATE_SCB page 3-44 
SESSION_ACTIVATED_ALLOCATION page 3-70 
PS page 5.0-8 
HS page 6.0-3 
FSM_SCB_STATUS_BIDDER page 3-85 
FSM_SCB_STATUS_FSP page 3-86 
LU_NAME page 3-91 
MODE_NAME page 3-91 
SESSION_INFORMATION page A-32 
RM_HS_CONNECTED page A-18 
SCB page A-8& 
RM_ACTIVATE_SESSION page A-16 
RM_SESSION_ACTIVATED page A-22 
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SUCCESSFUL_SESSION_ACTIVATION 


GET_SESSION page A-16 
YIELD_SESSION page A-19 
SESSION_ALLOCATED page A-22 
ENCIPHERED_RD2 page A-18 


Call CREATE_SCB(LU_NAME, MODE_NAME, SESSION_INFORMATION) (page 3-44). 
Create an RM_HS_CONNECTED record and send it to the HS 
identified by SESSION_INFORMATION.HS ID. 
If this is a primary half-session then 
Call #FSM_SCB_STATUS(R, SESSION_ACTIVATED, PRI) (page 3-84). 
Do until the activated session is used to service a waiting request, or 
the session is yielded: 
If a GET_SESSION request is waiting for a session to this partner LU and 
on this mode then 
If the session does not support the security level specified by the 
waiting request then 
Downgrade the specified security level to NONE. 
If the session does not support the sync level specified by the 
waiting request then 
Create a SESSION_ALLOCATED record with RETURN_CODE set to 
SYNC_LEVEL_NOT_SUPPORTED and send it to the PS (Chapter 5.1) associated 
with the waiting request. | 
Destroy the waiting GET_SESSION request. 
Else (session support is OK) 
If LU-LU verification is active (random data is present in the SCB) then 
Create an ENCIPHERED RD2 containing an FMH-12 (refer to SNA Formats) 


initialized with the enciphered version of the random data present in the SCB. 


Set ENCIPHERED_RD2.SEND_PARM.ALLOCATE to NO. 
Set ENCIPHERED_RD2.SEND_PARM.FMH to YES. 
Set ENCIPHERED_RD2Z.SEND_PARM.TYPE to FLUSH. 
Send the ENCIPHERED_RD2 to the HS (Chapter 6.0) representing 
the newly activated session. 
Call SESSION ACTIVATED _ALLOCATION(GET_SESSION, SCB.HS_ID) (page 3-70). 
Destroy the waiting GET_SESSION request. 
Else (no waiting requests) 
Call #FSM_SCB_STATUS(S, YIELD_SESSION, UNDEFINED) (page 3-84). 
If LU-LU verification is active (random data is present in the SCB) then 
Create an ENCIPHERED_RD2 containing an FMH-12 initialized with the enciphered 
version of the random data present in the SCB. 
Set ENCIPHERED_RD2.SEND_PARM.ALLOCATE to NO. 
Set ENCIPHERED_RD2.SEND_PARM.FMH to YES. 
Set ENCIPHERED_RD2.SEND_PARM.TYPE to DEALLOCATE_FLUSH (yields the session). 
Send the ENCIPHERED_RD2 to the HS (Chapter 6.0) representing 
the newly activated session. 
Else | 
Create a YIELD_SESSION record and send it to the HS (Chapter 6.0) 
representing the newly activated session. 
Else (secondary half-session) 
If LU-LU verification is active (random data is present in the SCB) then 
Call #FSM_SCB_STATUS(R, SESSION ACTIVATED, SECURE) (page 3-84). 
Else 
Call #FSM_SCB_STATUS(R, SESSION ACTIVATED, SEC) (page 3-84). 
If an RM_ACTIVATE_SESSION request is pending then 
Create an RM_SESSION_ACTIVATED record with RETURN_CODE set to OK and send 
it to the PS (Chapter 5.4) that originally issued 
the RM_ACTIVATE_SESSION record to RM. 
Destroy the pending RM_ACTIVATE_SESSION request. 
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TEST_FOR_FREE_FSP_SESSION 


This procedure tests for a free first-speaker half-session. If one is found, 
a new RCB_ is created and the support levels (conversation-level security and 
sync level) provided by the session are checked to see if they are compatible 
with those requested in the ALLOCATE_RCB. If they are not compatible, the 
RETURN CODE on the RCB_ALLOCATED record is set to indicate an unsuccessful 
allocation, or, in the case of a security incompatibility, the security level 
is downgraded to a compatible level. If the support levels are compatible, 
the half-session is allccated to the RCB, the ID of the RCB is placed in the 
passed RCB_ALLOCATED record. 


If a free first-speaker half-session is not found, the RETURN_CODE in the 
passed RCB_ALLOCATED record is changed to indicate an unsuccessful allocation. 


INPUT : ALLOCATE_RCB and RCB_ALLOCATED (the latter created by ALLOCATE_RCB_PROC ) 


OUTPUT : RCB_ALLOCATED with the RCB_ID field set to the ID of the allocated RCB, or 
with the RETURN_CODE set to UNSUCCESSFUL 


Referenced procedures, FSMs, and data structures: Meni? 
CREATE_RCB page 3-43 
SET_RCB_AND_SCB_FIELDS page 3-75 
CONNECT_RCB_AND_SCB page 3-42 
ALLOCATE_RCB page A-15 
RCB_ALLOCATED | page A-21 
RCB | page A-6 
SCB page A-8& 


If a free first-speaker session exists for ALLOCATE_RCB.LU_NAME and 
ALLOCATE_RCB.MODE_NAME then 
Call CREATE_RCB( ALLOCATE_RCB, RCB_ALLOCATED) (page 3-43). 
If the security level requested in the RCB.SECURITY_SELECT . 
is not supported by the partner LU then | 
Downgrade the requested level of security to NONE. a 
If the sync level requested in ALLOCATE_RCB is not supported by the partner LU then 
Set RCB_ALLOCATED.RETURN_CODE to SYNC_LEVEL_NOT_SUPPORTED. 
Else 
Call SET_RCB_AND_SCB_FIELDS(RCB_ID, HS_ID) (page 3-75). 
Call CONNECT _RCB_ AND SCB(RCB_ID, HS_ID) (page 3-42). 
Set the following fields in the RCB_ALLOCATED: RETURN_CODE to OK, 
SEND_RU_SIZE to SCB.SEND_RU_SIZE, LIMITED BUFFER_POOL_ID to 
SCB.LIMITED_BUFFER_POOL_ID, and PERMANENT _BUFFER_POOL_ID to 
SCB .PERMANENT_BUFFER_POOL_ID. 


Remove the session from the free-session pool. | soe 
“ : fe . 

Else (no free first-speaker sessions). 
Set RCB_ALLOCATED.RETURN_CODE to UNSUCCESSFUL. Ras 


C- 
we 
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UNSUCCESSFUL_SESSION_ACTIVATION 


FUNCTION: This procedure handles the processing that occurs when a new session could not 
be activated by the session manager. 


This procedure checks to see if any session has been activated for this 
(LU_NAME, MODE_NAME) pair. If so», no action is taken by this procedure. The 
(one or more) previously allocated sessions will eventually be available for 
use by the transaction programs that requested a session. Similarly, if no 
sessions have been activated for this (LU_NAME, MODE_NAME) pair, but there are 
outstanding (pending) session activation requests that the session manager has 
not yet responded to, no action is taken. Some of the pending requests may 
succeed in activating sessions, and these sessions can eventually be used by 
other transaction programs. 


If, on the other hand, no session has’ been successfully activated for this 
LU_NAME and MODE_NAME and there are no other pending activation requests for 
this LU_NAME and MODE_NAME (1.e., all session activation requests have been 
responded to by the session manager), the procedure will send a SES- 
SION_ALLOCATED record to all instances of presentation services that have 
requested sessions for this LU_NAME and MODE_NAME. 


The RETURN_CODE field of the SESSION_ALLOCATED record is set to UNSUCCESS- 
FUL_RETRY or UNSUCCESSFUL_NO_RETRY depending on the ERROR_TYPE parameter. 


INPUT: LU_NAME and MODE_NAME of the LU to which session activation was unsuccessful; 
and ERROR_TYPE, indicating RETRY or NO_RETRY 


OUTPUT : SESSION_ALLOCATED to PS, WAITING _REQUEST records destroyed, 
RM_SESSION_ACTIVATED records created and sent to PS, RM_ACTIVATE_SESSION 
records destroyed 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
ACTIVATE_NEEDED_SESSIONS page 3-24 
LU_NAME page 3-91 
MODE_NAME page 3-91 
GET_SESSION page A-16 
MODE page A-3 
RM_ACTIVATE_SESSION page A-16 
RM_SESSION_ACTIVATED page A-22 
SESSION_ALLOCATED page A-22 


Get addressability to the MODE control block associated with LU_NAME and MODE_NAME. 
If MODE .ACTIVE_SESSION_COUNT is O and MODE.PENDING_SESSION_COUNT is 0 then 
Do for each waiting request for a session 
to this partner (LU_NAME) using this mode (MODE_NAME): 
Create a SESSION_ALLOCATED record with RETURN_CODE set to 
UNSUCCESSFUL_RETRY or UNSUCCESSFUL_NO_RETRY according to 
ERROR_TYPE. 
Send the SESSION_ALLOCATED record to the PS (Chapter 5.1) 
that issued the original request. 
Destroy the waiting request. 
If this partner LU does not support parallel sessions and 
there are other waiting GET_SESSION requests for a session to this partner 
for a different mode then 
Try to activate a session for the other mode to satisfy a waiting request by 
calling ACTIVATE_NEEDED_SESSIONS(LU_NAME, MODE_NAME for the mode 
with waiting requests) (page 3-24). 
Do while the number of pending RM_ACTIVATE_SESSION operator requests is greater than 
the MODE .PENDING_SESSION_COUNT: . 
Create an RM_SESSION_ACTIVATED record with RETURN_CODE set to 
ACTIVATION_FAILURE_RETRY or ACTIVATION_FAILURE_NO_RETRY according to ERROR_TYPE. 
Send the RM_SESSION_ACTIVATED record to the PS (Chapter 5.1) 
that issued the original request. 
Destroy the pending RM_ACTIVATE_SESSION request. 
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#FSM_SCB_STATUS 


#FSM_SCB_STATUS is a generic FSM that main- 
tains the state of a half-session. There is 
one #FSM_SCB_STATUS for each session Known to 
the resources manager. #FSM_SCB_STATUS is 
initialized to either FSM_SCB_STATUS_BIDDER 
or FSM_SCB_STATUS_FSP, depending on the ses- 
sion polarity, when the resources manager 
becomes aware of the existence of a new ses- 
sion. This initialization occurs in CRE- 
ATE_SCB (page 3-44). 


The states of FSM_SCB_STATUS_BIDDER and 
FSM_SCB_STATUS_FSP are: 


e SESSION ACTIVATION--the initial state, 


following activation of the session 
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@ FREE--the session is free for use by a 
conversation 

® PENDING ATTACH--the session is in the 
in-bracket state and the local LU is 
waiting for an Attach FM header from the 
remote LU 

e IN USE--the session is in use by a con- 
versation 

@ PENDING FMH12--the session is waiting for 
the Security FM header from the remote LU 
before beginning normal Attach processing 


The first input denotes whether a record has 
been sent (S) or received (R) by RM, and the 


second input denotes the particular record 
type. PRI (primary), SEC (secondary), and 
SECURE (session-level security ) are 


half-session attributes. 


oo 


FSM_SCB_STATUS_BIDDER 


ae FSM_SCB_STATUS_BIDDER 


FUNCTION: To remember the status of a bidder half-session 


NOTES: 1. The initial state of this FSM is SESSION_ACTIVATION. 


2. When HS on the bidder side of a session receives an MU containing an Attach, 
HS generates a separate BID and sends it to RM. RM (bidder side) always sends 
a positive BID_RSP to HS (unless a protocol error has occurred). HS (bidder 
side) discards the BID_RSP and then sends the Attach MU to RM. RM on the 
first-speaker side does not generate the BID record, and does not expect a 
BID_RSP, since a first-speaker half-session always gains access to the ses- 
sion. 


A YIELD_SESSION changes the FSM from SESSION_ACTIVATION state to the IN_USE 
state. A FREE_SESSION record is expected from the half-session to then cause 
RM to change the state to FREE. 


\ 
S$ STATE NAMES---->] SESSION 


ACTIVATION 
INPUTS STATE NUMBERS-->] 01 


R» POS_BID_RSP | 


R» BID 
R» ATTACH 
R» FMH_12 


R, FREE_SESSION | 
CO S, YIELD_SESSION 


) R» SESSION_ACTIVATED, PRI 
R,» SESSION_ACTIVATED, SEC 
R,» SESSION_ACTIVATED, SECURE 


PENDING 
ATTACH 
03 


PENDING 
FMH12 
05 


aii y 
NNNODON NNN PN | OC 
sey _ 
m 
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FSM_SCB_STATUS_FSP 


To remember the status of a first-speaker half-session 
The initial state of this FSM is SESSION_ACTIVATION. 


A YIELD_SESSION changes the FSM from SESSION_ACTIVATION state to the IN_USE 
state. A FREE_SESSION record is expected from the half-session to then cause 
RM to change the state to FREE. 


PENDING 
FMH12 
05 


PENDING 
ATTACH 
03 


STATE NAMES~---->| SESSION 
ACTIVATION 
STATE NUMBERS-~-->/ O01 


S» GET_SESSION 


R, BID 
R» ATTACH 
R, FMH_12 


R, FREE_SESSION 


S» YIELD_SESSION 


R, SESSION_ACTIVATED, PRI 
R» SESSION_ACTIVATED, SEC 
R» SESSION_ACTIVATED, SECURE 


/ 
/ 
/ 
/ 
/ 
/ 


/ / 

4 / 

/ 3 
2 

7 / 

/ / 

/ / 


3 
/ 
/ 
/ 
/ 
/ 
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#FSM_BIS 


#FSM_BIS is a generic FSM that maintains the 
state of the BIS protocol for a half-session. 
There is one #FSM_BIS for each session Known 
to the resources manager. *#FSM_BIS is ini- 
tialized to either FSM_BIS BIDDER- or 
FSM_BIS_FSP, depending on the session polari- 
ty, when the resources manager becomes aware 
of the existence of a new session. This 
initialization occurs in CREATE_SCB (page 
3-44). 


FSM_BIS_BIDDER 


The states of FSM_BIS BIDDER and FSM_BIS_FSP 
are: 


e RESET--the initial state; BIS has been 
neither sent nor received 

@ BIS SENT--the local LU has sent BIS 

e BIS RCVD--the local LU has received BIS 

e CLOSED--the local LU has both sent and 
received BIS 


The first input denotes whether a record has 
been sent (S) or received (R) by RM, and the 
second input denotes the particular record 


type. 


FUNCTION: To remember the status of a bidder half-session with respect to BIS_RQ and 


BIS REPLY 


NOTES: 1. The initial state of this FSM is RESET. 


2. After BIS_RQ and BIS_REPLY have been exchanged over a session, this FSM will 
be in the CLOSED state, indicating that the session is being deactivated. The 
CLOSED state is a terminating state, in that the FSM will not leave this state 
until it (along with its corresponding SCB) is destroyed. 


Referenced procedures, FSMs, and data structures: 
SEND_DEACTIVATE_SESSION 
CHECK_FOR_BIS_REPLY 
BIS _RACE_LOSER 
SEND_DEACTIVATE_SESSION 
HS_ID 


STATE NAMES----> 


INPUTS STATE NUMBERS--> 


S, BIS_RQ 
R,» BIS_REPLY 


R, BIS_RQ 
S, BIS_REPLY 


ERROR 


RESET 

01 

2 / 
>CERROR ) 4(A) 
3(B) 4(C) >C ERROR ) 

/ / 4 
OUTPUT FUNCTION ; 

CODE 7 


Call SEND_DEACTIVATE_SESSION( ACTIVE, HS_ID, NORMAL, X'00000000') (page 3-68). 


ie Call CHECK_FOR_BIS_REPLY(HS_ID) (page 3-40). 


Call BIS_RACE_LOSER(HS_ID) (page 3-38). 


Call SEND_DEACTIVATE_SESSION( ACTIVE, HS_ID, ABNORMAL, X'20100000') (page 3-68). 


BIS CLOSED 
RCVD 
03 04 
/ / 
>( ERROR ) / 
/ 
/ 
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FSM_BIS_FSP 
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FSM_BIS_ FSP | . = 


FUNCTION: To remember the status of a first-speaker half-session with respect to BIS_RQ 
and BIS_REPLY | 


NOTES: 1. The initial state of this FSM 1s RESET. 


2. After BIS_RQ and BIS_REPLY have been exchanged over a session, this FSM will 
be in the CLOSED state, indicating that the session is being deactivated. The 
CLOSED state is a terminating state, in that the FSM will not leave this state 
until it (along with its corresponding SCB) is destroyed. 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-68 
CHECK_FOR_BIS_REPLY page 3-40 
HS_ID page 3-91 


STATE NAMES---->| RESET BIS BIS | CLOSED 
7 SENT RCVD 
INPUTS STATE NUMBERS-->] 01 02 03 04 
S, BIS_RQ 2 / / / 
R» BIS_REPLY >( ERROR ) GCA) >( ERROR ) / 
R,» BIS_RQ 3(B) - >( ERROR ) / 
S, BIS_REPLY / / 4 / 


OUTPUT FUNCTION 
CODE 


naa Call SEND_DEACTIVATE_SESSION( ACTIVE, HS_ID» NORMAL, X'00000000') (page 3-68). 


Call CHECK_FOR_BIS_REPLY(HS_ID) (page 3-40). 


ERROR Call SEND_DEACTIVATE_SESSION( ACTIVE, HS_ID, ABNORMAL, X'20100000') (page 3-68). 


C) 
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#FSM_RCB_STATUS 


#FSM_RCB_STATUS is a generic FSM that main- 
tains the state of a conversation resource. 
There is one #FSM_RCB_STATUS for each conver- 
sation Known to the resources manager. When 
resources manager creates the conversation 
resource, #FSM_RCB_STATUS is initialized to 
either FSM_RCB_STATUS_BIDDER or 
FSM_RCB_STATUS_FSP, depending on the polarity 
of the underlying session. This initializa- 
tion occurs in BIDDER_PROC (page 3-37), CRE- 
ATE_RCB (page 3-43), and PS_CREATION_PROC 
(page 3-55). 


FSM_RCB_STATUS_ BIDDER 


FUNCTION: 
half-session 


The states of FSM_RCB_STATUS_BIDDER' and 
FSM_RCB_STATUS_FSP are: 


e FREE--the initial state; the conversation 
is inactive 

e IN USE--the conversation is in progress 

¢ PENDING SCB (BIDDER only)--the conversa- 
tion is awaiting allocation of a session,» 
pending receipt of RSP(Bid) 


The first input denotes whether a record has 
been sent (S) to RM by PS or received (R) by 
RM from HS, and the second input denotes the 
particular record type. HS (half-session) 
represents the sender of the Attach. 


To remember the status of a conversation resource associated with a bidder 


NOTES: . The initial state of this FSM is FREE. 


The RCB may be in the FREE state when a DEALLOCATE_RCB is issued if RM discov- 
ers that an ALLOCATION_ERROR exists before it attempts to get a session for 


the transaction program. 


The ALLOCATION_ERRORs that can occur in this situ- 


ation are ALLOCATION_FAILURE_* and SYNC_LEVEL_NOT_SUPPORTED_BY_LU. 


INPUTS 


POS_BID_RSP 
- NEG_BID_RSP 


STATE NAMES~-~-> 


STATE NUMBERS--> 


GET_SESSION 


» ATTACH, H 
DEALLOCATE_RCB 


PENDING 
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FSM_RCB_STATUS_FSP 


FUNCTION: To remember the status of a conversation resource associated with a 
first-speaker half-session 


NOTES: . The initial state of this FSM is FREE. 


The RCB may be in the FREE state when a DEALLOCATE_RCB is issued if RM discov- 
ers that an ALLOCATION_ERROR exists before it attempts to get a session for 
the transaction program. |The ALLOCATION_ERRORs that can occur in this situ- 
ation are ALLOCATION _FAILURE_* and SYNC_LEVEL_NOT_SUPPORTED_BY_LU. 


STATE NAMES----> 


INPUTS STATE NUMBERS--> 


S, ALLOCATE_RCB 
S, GET_SESSION 


R, ATTACH, HS 


S, DEALLOCATE_RCB 
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LOCAL DATA STRUCTURES 


LU_NAME 


LU_NAME: LU name of a partner LU 
MODE_NAME: mode name 


HS_ID: half-session identifier 


a 
~ 


RCB_ID: conversation resource identifier 


TCB_ID 


TCB_ID: TP-PS process identifier 
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SENSE_CODE 


ase 


SENSE_CODE: 4-byte sense data 


PREVIOUS_TIME | 


PREVIOUS TIME: 48-bit time value 


RESPONSE_CODE 


RESPONSE_CODE: possible values: OK, PIP_NOT_ALLOWED, PIP_NOT_SPECIFIED_CORRECTLY> 
TPN_NOT_RECOGNIZED, TRANS_PGM_NOT_AVAILABLE_RETRY 
TRANS_PGM_NOT_AVAIL_NO_RETRY, SECURITY_NOT_VALID, 
PS_CREATION_FAILURE, INVALID _FULLY_QUALIFIED_LU_NAME ); “<= 
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CHAPTER 4. LU SESSION MANAGER 
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Node 
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Facility 


Resources 
Manager 


Session 
Services 


Address 
Space 
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LU-LU 
Node Half-Session 
Buffer 
Manager 


Note: Only the components having a protocol boundary with LU session manager are shown. 


Figure 4-1. Protocol Boundaries between LU Session Manager and Other Node Components 


GENERAL DESCRIPTION 


This chapter describes the session manager session-control RUs performs the actual acti- 
(SM) component within an LU. Figure 4-1 vation and deactivation of the sessions. The 
shows the LU session manager and its relation exchange of records between the LU and CP 
to other components within the node. The precedes and follows the activation and deac- 
arrows joining the components represent the tivation of the sessions. 
protocol boundaries that exist between SM and 
the other components. Session-control requests and responses are 
sent on the expedited flow with the RU cate- 
The LU session manager initiates and termi- gory indicating session control (SC). Full 
nates sessions in response to requests from details of the formats are given in SNA For- 
the resources manager and from the remote LU. mats. 
me The initiation and termination of sessions The LU resources manager (RM) in one of the 
C) involves exchanging records between the LU partner LUs directs the activation or deacti- 
and the local control point (CP), and vation of an session. Upon completion of the 
exchanging session-control RUs between the LU activation or deactivation, SM in each of the 


and ae partner’ LU. The exchange of 
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two LUs informs its local RM that the session 
has been activated or deactivated. 


. OVERVIEW OF SESSION INITIATION 


RM directs the LU to activate a session by 
sending SM an ACTIVATE_SESSION record across 
an internal protocol boundary. SM processes 
the ACTIVATE_SESSION record and initiates the 
session. The SM components in the two LUs 
activate the session by exchanging a BIND 
request and response. SM's processing of the 
ACTIVATE_SESSION record, which constitutes 
its part of the session initiation, includes 
the following: 


° Check if by activating the session a ses- 
sion limit would be exceeded. 


e Send the ASSIGN_PCID record to the ses- 
sion services (SS) component of the con- 
trol point requesting a fully qualified 
procedure correlator identifier (FQPCID), 
which will uniquely identify the session 
and procedures related to the session. 
The FQPCID is assigned by the node initi- 
ating the session. 


e Receive the ASSIGN_PCID_RSP record from 
SS. This record contains a Fully Quali- 
fied PCID (FQPCID) control vector. 


e Send an INIT_SIGNAL record to SS. _ The 
request directs the control point to 
mediate the initiation of the session. 


e Receive a CINIT_SIGNAL record from SS. 
That record contains the path control ID 
and characteristics (e.g.» maximum send 
and receive BTU sizes) for the session 
and the information on what to include in 
the BIND. 


e Send an ASSIGN_LFSID record to the 
address space manager (ASM) component of 
the control point. This record asks ASM 
to assign a local-form session identifier 
(LFSID) for the session. The LFSID log- 
ically connects a half-session (HS) with 
the path control (PC). 


e Receive an ASSIGN_LFSID_RSP record with 
the LFSID for the session from ASM. 


e Send the BIND with the desired parameters 
for the session to the partner (second- 
ary) LU. 


e Receive the RSP(BIND) with the negotiated 
session parameters from the partner. 
Check the admissibility of the negotiated 
parameters. 


e Obtain buffers for the session from the 
node's buffer manager (BM). These buff- 
ers will be used by the half-session HS. 


e Create and initialize the HS for this 
LU's side of the session. 


e Notify RM that the requested session is 
active. 


Peer Protocols 


The partner LU of the one initiating the ses- 
sion is directed to activate the session by 
means of receiving the BIND. Its processing 
following receipt of the BIND includes the 
following: 


e Obtain buffers for the session from BM. 
These buffers will be used by HS. 


°® Build a negotiated BIND response that 
specifies the agreed-to parameters for 
the session, and send the BIND response 
to the partner (primary) LU. 


e Create and initialize the HS for this 
LU's side of the session. 


e Notify SS that a new session is acti- 
vated. 


° Inform RM that a session has been acti- 
vated at the request of the remote LU. 


The parameters used for the session and car- 
ried in the BIND request and response have 
the following sources: 


e Fixed parameters: These have fixed val- 
ues for all BIND requests and responses 
for LU 6.2 sessions. 


e Implementation-dependent parameters: 
These have values that are determined 
during the implementation of the node. 


e Installation-specified parameters: These 
have values that are determined by the 
user at the node's installation. | 


e CINIT parameters: These have values tak- 
en from the CINIT_SIGNAL record and sent 
in the BIND. 


OVERVIEW OF SESSION TERMINATION 


RM directs the LU to deactivate a session by 
sending SM a DEACTIVATE_SESSION record across 
an internal protocol boundary. The two LUs 
deactivate their session by exchanging an 
UNBIND request and response and destroying 
their local half-sessions. SSM's processing 
of the DEACTIVATE_SESSION record, which con- 
stitutes its part of the session termination; 
includes the following: 


e Send an UNBIND to the partner LU and 
receive the RSP(UNBIND). SM deactivates 
the session upon sending the UNBIND;, 
before getting the RSP(UNBIND). 


e Notify SS that the session has been deac- 
tivated. 


e Destroy the HS for this LU's side of the 
session. 


e Inform BM that buffers previously 
reserved for the session are no longer 
needed. 


CC 


Mae we 


Ne a 


‘és 


The partner LU of the one terminating the 
session is directed to deactivate the session 
by means of the UNSBIND. Its processing fol- 
lowing receipt of the UNBIND is similar to 
the processing just outlined. SM at the 
UNBIND receiver informs RM that it has deac- 
tivated a session at the request of the 
remote LU. | 


SESSION OUTAGE AND SESSION REINITIATION 


An active session between two LUs may be 
interrupted by a failure of one or both of 
the LUs, by an abort of one or both of their 
HSs, or by a failure of the path that con- 
nects the LUs. This interruption causes a 
session outage, and notification to the LU of 
the session outage is referred to as 
session-outage notification, or SON. When SM 
receives a SESSION_ROUTE_INOP record from 


ASM, it notifies RM, SS, and BM and destroys 
the HS for each session affected by the ses- 
sion outage. 


When session outage occurs, RM may direct SM 
to reinitiate the sessions. See "Chapter 3. 
LU Resources Manager" and "Chapter 5.4. Pres- 
entation Services--Control-Operator Verbs" 
for more details. 


PLU AND SLU 


PLU and SLU refer to the role of an LU in 
providing, respectively, primary or secondary 
half-session control for a session. The PLU 
sends the INIT_SIGNAL record, receives the 
CINIT SIGNAL record, sends the BIND, and 
receives the RSP(BIND). Conversely, the SLU 
receives the BIND and sends the RSP(BIND). 
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SM PROTOCOL BOUNDARIES 


This section describes the protocol bounda- 
ries (PBs) that SM has with various LU and 
other node components. SM interacts with 
them by exchanging records. Figure 4-2 shows 
the protocol boundaries and lists the record 
names associated with them. The procedures 
and finite-state machines (FSMs) of this 
chapter describe SM's protocols for sending 


and receiving these records. See "Appendix 
A. Node Data Structures" for a definition of 
the formats of these records. 


In addition, SM interacts with the node's 
buffer manager. See "SM and Buffer Manage- 
ment" on page 4-28 for a detailed description 
of this protocol boundary. 


LU Resources Manager 


Hal f-Session 


Node Operator Facility 


>| Node Operator Facility | 


CP Address Space Manager 


(A) 
(B) 
(C) > 
(D) 
LU Session 
Manager = (E.) 
(F) 
(G) 
(H) 
(I) 


Records that SM sends: 


CP Session Services 


Records that SM recelves: 


(A) ACTIVATE_SESSION_RSP (B} ACTIVATE_SESSION 
SESSION_ACTIVATED DEACTIVATE_SESSION 
SESSION_DEACTIVATED ABEND_NOTIFICATION 

(C)} INIT_HS (D) INIT_HS_RSP 

ABORT_HS 
(E)} RM_CREATED ABEND_NOTIFICATION 
(F) MU (contains the following RUs) (G) MU (contains the following RUs) 
BIND BIND 
UNBIND | UNBIND 
*tRSP( BIND ) +RSP( BIND } 
*+RSP(UNBIND ) SESSION_ROUTE_INOP 
PC_HS_DISCONNECT ASSIGN_LFSID_RSP 
ASSIGN_LFSID LFSID_IN_USE 
FREE_LFSID | 
LFSID_IN_USE_RSP 

(H)} ASSIGN_PCID (I) ASSIGN_PCID_RSP 
INIT_SIGNAL INIT_SIGNAL_NEG_RSP 
SESSST_SIGNAL CINIT_SIGNAL 
SESSEND_SIGNAL ~ 

Figure 4-2. Records Exchanged between SM and Other Components 
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PB WITH RM 
This section describes the records that SM 
exchanges with RM. 


The following table lists each record and the 
page number of its description. 


ACTIVATE_SESSION 


Flow: From RM to SM 


ACTIVATE_SESSION instructs SM to activate a 
session with a specified partner LU using a 


DEACTIVATE_SESSION 


Flow: From RM to SM 


DEACTIVATE_SESSION instructs SM to deactivate 
a specific session. SM correlates this 
request to a specific session either by HS_ID 
(a half-session process identifier), if RM 


ABEND_NOTIFICATION 


Flow: From RM to SM 


ABEND_NOTIFICATION informs SM that RM has 
abended. SM will bring down all of its ses- 


ACTIVATE_SESSION_RSP 


Flow: From SM to RM 


ACTIVATE_SESSION_RSP tells RM whether or not 
SM was able to satisfy RM's request to acti- 
vate a session. If positive, ACTI- 
VATE_SESSION_RSP contains a_ half-session 
process identifier, which will be used by RM 


Record Page 


ACTIVATE_SESSION 4 
DEACTIVATE_SESSION 4 
ABEND_NOTIFICATION 4- 
ACTIVATE_SESSION_RSP 4 
SESSION_ACTIVATED A 
SESSION_DEACTIVATED 4 


Given mode name. RM expects a response (pos- 
itive or negative) to this request. 


has already been informed that the session is 
activated, or by the CORRELATOR parameter, 
which matches that from an ACTIVATE_SESSION 


record. 


sions, and will inform all affected compo- 
nents in the node. 


to identify the session. If negative, ACTI- 
VATE_SESSION_RSP uses an ERROR_TYPE parameter 
to inform RM whether another attempt to acti- 
vate a session might succeed. 
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SESSION_ACTIVATED 


Flow: From SM to RM 


SESSION_ACTIVATED tells RM that SM has acti- 
vated a session at the request of a partner 
LU. 


~ SESSION_DEACTIVATED 


Flow: From SM to RM 


SESSION_DEACTIVATED tells RM that SM _ has 
deactivated a session either at the request 
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of a partner LU, because of a detected proto- 
col violation, or following a link failure. 


a 


E3 
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PB WITH HS 
This section describes the records that SM 
exchanges with HS. 


The following table lists each record and the 
page number of its description. 


INIT_HS 


Flow: From SM to HS 


INIT_HS gives HS all the session information 
it needs to begin to perform its functions. 
This information includes the values of the 
negotiated session parameters (see details in 
the later description of the BIND request and 


INIT_HS_RSP 


Flow: From HS to SM 


INIT_HS_RSP tells SM whether or not the HS is 
successfully initialized. The only reason an 


ABORT_HS 


Flow: From HS to SM 


ABORT_HS informs SM that a HS has abnormally 
terminated because of a protocol violation. 
SM will bring down the session and inform the 


ABEND_NOTIFICATION 


Flow: From HS to SM 


ABEND_NOTIFICATION informs SM _ that HS has 
abnormally terminated. SM will bring down 
all sessions associated with the HS, and will 


Record Page 


INIT_HS G-7 

INIT_HS_RSP ; 4-7 
ABORT_HS 4-7 
ABEND_NOTIFICATION 4-7 


response RUs) and the buffer pool identifiers 
for the buffers obtained by SM on behalf of 
this HS. The buffer identifier is a pointer 
to a buffer manager control block for the 
buffer pool. 


HS activation could fail is the failure of 
the cryptography verification. 


partner LU, and the RM and SS components in 
its own node of the condition. 


inform RM and SS in this node of the condi- 
tion. 
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PB WITH NOF 


This section describes the records that SM 
exchanges with NOF. 


RM_CREATED 


Flow: From SM to NOF 


RM_CREATED informs NOF that SM has success- 
fully created an RM process so that NOF can 
start its first transaction program on the 
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The following table lists each record and the 


page number of its description. a 
Record Page eS 
RM_CREATED 4-8 


LU. This record is sent by SM only once dur- 
ing it's initialization stage. 


CY 


ps 
uy 


PB WITH SS 


This section describes the records that flow 
between SM and the session services component 
of the CP. 


The following table lists each record and the 
page number of its description. 


ASSIGN_PCID 


Flow: From SM to SS 


ASSIGN_PCID record is sent by the session 
manager to the session services (SS) compo- 
nent of the node control point. ASSIGN_PCID 
asks SS to create a fully qualified procedure 
correlator (FQPCID) that will serve as a 
unique identifier for this session. This 
record is sent after SM receives a request to 
activate a session from RM or when it 
receives a BIND that does not contain an 


ASSIGN_PCID_RSP 


Flow: From SS to SM 


ASSIGN_PCID_RSP record is sent to the session 
manager by the session services component of 
the node control point. This record is sent 
after SS receives a request from the session 
manager to assign an FQPCID control vector 
for the session. 


When SM receives the ASSIGN_PCID_RSP record, 
it compares the PCID portion of the received 


INIT_SIGNAL 


Flow: From SM to SS 


INIT_SIGNAL requests that the CP assist in 
the initiation of a session between the LU 
sending the request (the PLU) and the LU 
named in the request (the SLU). The 
INIT_SIGNAL requires a response from the con- 
trol point. 


Record Page 


ASSIGN_PCID 4-9 
ASSIGN_PCID_RSP 4-9 
INIT_SIGNAL 4-9 


INIT_SIGNAL_NEG_RSP 4-10 
CINIT_SIGNAL 4-10 
SESSST_SIGNAL 4-10 
SESSEND_SIGNAL 4-10 


FQPCID control vector. ASSIGN_PCID asks SS 
to create an FQPCID that will serve as a 
local session identifier. In this latter 
case, FQPCID will never be sent to the part- 
ner LU. ASSIGN_PCID requires a response from 
ss. SM cannot accept any other’ signal 
related to any session until a response to a 
sent ASSIGN_PCID is received. 


FQPCID with those of all of its active and 
pending-active sessions. If a duplicate PCID 
is found, SM sends another ASSIGN_PCID record 
to SS indicating that it has discovered a 
PCID collision. This will continue until SS 
returns an ASSIGN_PCID_RSP record with an 
FQPCID whose PCID portion is not duplicated. 


The INIT_SIGNAL request contains, among other 
parameters, the fully qualified network names 
of the PLU and the SLU, the mode name for the 
session, and the FQPCID for the session. 


The CP returns either a CINIT_SIGNAL record 
or an INIT_SIGNAL_NEG_RSP record. 
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INIT_SIGNAL_NEG_RSP 


Flow: From SS to SM 


INIT_SIGNAL_NEG_RSP is sent by SS to SM in 
response to an INIT_SIGNAL record. 
INIT_SIGNAL_NEG_RSP tells the PLU that a 


request to activate a session is rejected. 
SM will then inform RM that it couldn't acti- 
vate a session. 


CINIT_SIGNAL 


Flow: From SS to SM C 


CINIT_SIGNAL is sent by SS to SM in response 
to an INIT_SIGNAL _ record. CINIT_SIGNAL 
instructs the PLU to send a BIND to the SLU 
and provides the information that the PLU 
needs in order to generate the BIND RU. See 
the description of BIND in this chapter for 
the rules of how the PLU chooses the BIND 


parameters. 


The PLU uses the FQPCID control vector field 
in the CINIT_SIGNAL record to correlate it to 
a previously sent INIT_SIGNAL. This field is 
always present in the CINIT_SIGNAL. The 
Class-of-Service/Transmission_Priority | con- 
trol vector (COS_TPF) may be present in the 
CINIT_SIGNAL record. If it is present, the 
PLU puts it in the BIND without modification. 


(> 


"Sy 5p oe 


SESSST_SIGNAL 


Flow: From SM to SS 


SESSST_SIGNAL notifies SS that a session has because Ss assumes after sending a/ ~ 


4-10 


been successfully activated. This record is 
sent to SS after SM sends a positive response 
to BIND. 


SESSST_SIGNAL is sent by SM only from the SLU 
side. On the PLU side, it is not necessary 


SESSEND_SIGNAL 


Flow: From SM to SS 


SESSEND_SIGNAL notifies SS that a session has 
been successfully deactivated or that an 
attempt to activate a session has failed. 
The former case applies to both PLU and SLU; 
the latter case applies only to the PLU in 
the situation when CP sent a CINIT_SIGNAL 
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activated. 


CINIT_SIGNAL record that the session will be | 
If the session activation fails 
after the CINIT_SIGNAL is received, the PLU's 
SM sends a SESSEND_SIGNAL record to SS. 


record to the PLU but the PLU could not suc- 
cessfully complete the session activation. 


SESSEND_SIGNAL carries the FQPCID control 
vector field and the sense data information. 


* 


, 
Sere 


PB WITH ASM 


This section describes the records that flow 
between the SM and the Address Space Manager 
component of the CP. 


The following table lists each record and the 
page number of its description. 


MESSAGE UNIT (MU) 


Flow: From SM to ASM and from ASM to SM 


Message unit (MU) records carrying the TH, 
RH, and session-activation and 
session-deactivation RUs are exchanged 
between SM and the address space manager com- 
ponent of the control point in_ both 
directions. 


SM receives a BIND MU in a session buffer 
that may be reused by the SM to send the 
response to the BIND, whether it be a 


PC_HS_DISCONNECT 


Flow: From SM to ASM 


PC_HS_DISCONNECT record is sent by SM to ASM 
after SM receives -RSP( BIND). 
PC_HS DISCONNECT instructs ASM to free the 
LFSID (local-form session identifier) used 
for the session. The reason why this record 
is sent only after a -RSP(BIND) is received 


SESSION_ROUTE_INOP 


Flow: From ASM to SM 


SESSION _ROUTE_INOP tells SM to terminate each 
session with an LULU_CB control block entry 
that has the PATH_CONTROL_ID parameter equal 


Record Page 


MU 4-11 


PC_HS_DISCONNECT 4-11 
SESSION_ROUTE_INOP 4-11 
ASSIGN_LFSID 4-12 
ASSIGN_LFSID_RSP 4-12 
FREE_LFSID 4-12 
LFSID_IN_USE 4-12 
LFSID_IN_USE_RSP 4-13 


+RSP(BIND) or an UNBIND. All other MU types 
arrive at SM in a link buffer that SM frees 
immediately. For a description of buffer 
types, refer to "SM and Buffer Management" on 
page 4-28. 


BIND, RSP(BIND), UNBIND, and RSP(UNBIND} RUs 
are described in greater detail later in this 
chapter. The format of MU records is defined 
in Appendix A. 


is that in all other cases SM sends either an 
UNBIND or a RSP(UNBIND) before the session is 
terminated. Both of these MUs contain a 
FREE_LFSID field, which SM sets to instruct 
ASM to free the LFSID. 


to the corresponding value received in the 


SESSION_ROUTE_INOP record. 
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ASSIGN_LFSID 


Flow: From SM to ASM 


ASSIGN_LFSID is sent by SM to the address 
space manager component of the control point 
after SM receives the CINIT_SIGNAL record. 
The purpose of this record is to request ASM 
to assign an LFSID’ for the’ session. 


ASSIGN_LFSID_RSP 


Flow: From ASM to SM 


ASSIGN_LFSID_RSP is received by SM from the 
address space manager component of the con- 
trol point in response to ASSIGN_LFSID. 
ASSIGN_LFSID_RSP carries the LFSID for the 


FREE_LFSID 


Flow: From SM to ASM 


FREE_LFSID is sent by SM to the address space 
manager component of ‘the control point when 
SM gets an ASSIGN_LFSID_RSP record from ASM 


LFSID_IN_USE 


Flow: From ASM to SM 


LFSID_IN_USE is received by SM from the 
address space manager component of the con- 
trol point when ASM needs SM to check whether 
a certain (PATH_CONTROL_ID, LFSID) pair is in 
use by the session manager. ASM may need to 
check if SM is using an LFSID because of the 
following race condition. Upon sending an 
UNBIND, the UNBIND sender may reuse an LFSID 
for a subsequent BIND that arrives at the 
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ASSIGN_LFSID requires a response from ASM. 
SM cannot accept any other signal related to 
any session until a response to aé_e sent 
ASSIGN_LFSID is received. 


session, except when ASM was unable to assign 
it. In this latter case, ASM sets the sense 
data field in the record to a nonzero value. 


but SM is unable to send a BIND because of an 
error encountered during initiation, such as 
lack of a BIND buffer. 


partner LU before the partner has fully proc- 
essed the preceding UNBIND and freed the 
LFSID for re-use on its side. In this case, 
the receiving ASM checks on the LFSID status 
with its SM (using this signal queued behind 
the pending UNBIND) to accommodate the race 
condition. See SNA Type 2.1 Node Reference 
for further details. : 


an 
Se 


, 


C) 


LFSID_IN_USE_RSP 


Flow: From SM to ASM 


LFSID_IN_USE_RSP is sent by SM to the address 
space manager component of the control point 
in response to the LFSID_IN_USE record. It 


contains a parameter that indicates whether a 
(PATH_CONTROL_ID, LFSID) pair in question is 


used by SM. 
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TH AND RH PARAMETERS 


See Figure 4-3 and Figure 4-4 on page 4-15 
for a description of TH parameters and Fig- 
ure 4-5 on page 4-16 and Figure 4-6 on page 
4-17 for a description of RH parameters in 


Field 
Offset in TH Name Value 


Byte 0 Bits 0-3 A 
Bit 4 
Bit 5 
Bit 6 
Bit 7 
Byte 1 Bits 0-7 | reserved | 00000000 BIND | UNBIND 
Byte 2. Bits 0-7 00000000 
Byte 3 Bits 0-7 00000000 
Bytes 4-5 | SNF unique 
sequence 
number V 
ee eee) eee [pee reee 
Byte 0 Bits 0-3 A 
Bit 4 
Bit 5 
Bit 6 
Bit 7 
Bits 0-7 00000000 RSP( BIND ) | 
RSP ( UNBIND 
Bytes 4-5 sequence 
| number 
from the 
request V 


Note: The FID type is set by path control (PC). 


Figure 4-3. TH Parmeters for MUs That SM Sends. 
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MUs that SM sends and receives. The meaning 
of the individual TH and RH bits is described 
in SNA Formats. 


) 


Bits 0-3 
Bit 4 
Bit 5 
Bit 6 
Bit 7 


Byte 1 Bits 0-7 (Note 1) 
Byte 2 Bits 0-7 (Note 1) 
Byte 3 Bits 0-7 (Note 1) 


Bytes 4-5 unique 
| sequence 
number 5 
copied in 
the RSP > 
if sent 
(Note 4) 
eae See ae 
Byte 0 Bits 0-3 
Bit 4 
Bit 5 
Bit 6 
Bit 7 


1) 
Byte 1 Bits 0-7 (Note 1) 
Byte 2 Bits 0-7 (Note 1) 


Byte 3. Bits 0-7 SOArS | (Note 1) 
Bytes 4-5 (Note 3) 


Notes: 


BIND | UNBIND 


RSP(BIND) (Note 4) 


1. This parameter is'checked by either PC or ASM not by SM. 

~EBIU, SM sends an UNBIND except when SM has already 
lost its awareness of the session, in which case it merely discards the received response. 

3. The SNF parameter correlates the response with the previously sent BIND. 

4. The session clean-up is done when the UNBIND is sent by SM3 SM does not wait for the RSP(UNBIND). 


2. If a +RSP(BIND) is received with EBIUI 


Figure 4-4. 


TH Parameters for MUs That SM Receives 
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Field 
Offset in RH Name Value 


Bit O A 
Bits 1-2 
Bit 3 
Bit 4 
Bit 5 
Bit 6 
Bit 7 
0 BIND | UNBIND 
1 reserved 
2 DR2I 
3 ERI 
q reserved 
5 RLWI 
6 QRI 
7 PI 
BBI 
EBL 
CDI 
reserved 
CEBI Vv 
RRI RSP A 
RU_CTGY | SC 
Category! SC 
reserved 0 
FMH 
(Note ) 
BC 
EC 
RSP( BIND ) | 
DR1 RSPCUNBIND ) 
reserved 0 
DR2I -~DR2Z 
RTI + 
Bits 4-5 reserved 00 
Bit 6 QRI -QR 
Bit 7 PI ~PAC 


Note: SDI is set to SD when a -RSP(BIND|UNBIND) is sent by SM; otherwise, it is set to -SD. 


Figure 4-5. RH Parameters for MUs That SM Sends 
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BIND |UNBIND 
reserved 

DR2I 

ERI 

reserved 

RLWI 

QRI 

PI 


BBI 
EBI 
cDI 
reserved 


RSP(BIND) (Note 3) 


reserved 
DR2I 

RTT 
reserved 
QRI 

PI 


Byte 2 Bits 0-7 (Note 2) Vv 
* Notes: 


1. SDI is set to SD when a -RSP(BIND) is received by SM; otherwise, it is set to ~SD. 
2. This parameter is checked by either PC or ASM, not by SM. 
3. The session clean-up is done when the UNBIND is sent by SM; SM does not wait for the RSP(UNBIND). 


_ Figure 4-6. RH Parameters for MUs That SM Receives 
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The following sections define some parameters 
that are common to many interprocess records 
and session-control field-formatted RUs. 


NETWORK-QUALIFIED NAME 


A network-qualified name is the name by which 
an LU is Known throughout an interconnected 
SNA network. An interconnected network com- 
prises one or more individual subnetworks. A 
network-qualified name consists of a network 
identifier (identifying the individual sub- 
network ) and a network LU name. 
Network-qualified names are unique throughout 
an interconnected network. 


LOCAL NAME 


A local name is any name by which a trans- 
action program at one LU Knows another LU. A 
local name requires interpretation (or trans- 
formation) by SM in order to yield the net- 
work qualified name of the partner LU. A 
local name may be the same as a 
network-qualified name. 


MODE NAME 


The CP has information about the LU partner 
that aids in the construction of the BIND 
parameters (carried in CINIT SIGNAL). The CP 
and SM derive additional information from the 
mode name. The local LU supplies the mode 
name in the INIT_SIGNAL record. 


LU-LU VERIFICATION DATA 


Random data and enciphered data are used for 
LU-LU verification. Random data is randomly 
generated data of symbol-string type G. 
Enciphered data is the enciphered version of 
the random data. 


If LU-LU verification is active, BIND and 
RSP(BIND) will contain 8 bytes of random data 
generated by the sender for LU-LU verifica- 
tion. RSP(BIND) will also contain 8 bytes of 
enciphered data for the same purpose. The 
secondary LU submits the random data received 
in the BIND along with the LU-LU password 
(refer to "Security" on page 2-9) to the Data 
Encryption Standard (DES) algorithm to obtain 
enciphered data. This enciphered data is 
inserted in the RSP(BIND) along with new ran- 
dom data. When the primary LU receives the 
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RSP(BIND), it compares the received enci- 
phered data with a copy of the same random 
data that it has also enciphered using its 
copy of the LU-LU password and the DES algo- 
rithm. If they are identical, the primary LU 
has verified that the SLU has the correct 
LU-LU password. 

Up to this point in the LU-LU verification 
process, processing has been done by the SM 
of each LU. SM in the primary and secondary 
LUs send to their respective RMs a record 
that contains the random data from the 
RSP(BIND). The primary LU‘s RM enciphers the 
random data using the LU-LU password and the 
DES algorithm, inserts it in a Security FM 
header (refer to "Chapter 3. LU Resources 
Manager" in Chapter 3) and sends it to the 
secondary's RM. The received enciphered data 
1s compared with the secondary LU's version 
of the enciphered data. If they are identi- 
cal, the secondary LU has verified that the 
primary LU has the correct LU-LU password, 
which completes the process. 


SPECIFICATION OF RU PARAMETERS 


Throughout the descriptions of the RUs in 
this chapter, reference is made to the spec- 
ification of a parameter. "Specification" 
refers to a specific value that is supplied 
for the parameter when the RU is being built, 
prior to its being sent. 


Implementation-Dependent Parameters 


Throughout the descriptions of the RUs in 
this chapter » reference 1s made to 


imp lLementation-dependent parameters. 
"Implementation-dependent" means that the 


particular value, or values, that a parameter 
of an RU can take is determined by each 
implementation. 


Installation-Specified Parameters 


Throughout the descriptions of the RUs in 
this chapter ,» reference 1s made to 
installation-speci fied parameters. 
"“Installation-specified" means that the par- 
ticular value, or values, that a parameter of 
an RU can take is determined by the installa- 
tion owner or manager. 
Installation-specified values can be estab- 
lished during system definition of a node, or 
later during its operation. The method for 
establishing values of installation-speci fied 
parameters is implementation-dependent. 
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This section describes the session-control 
requests and responses that SM sends and 
receives. 


Each RU description includes the RU flow and 
a discussion of the function and use of the 
RU. Refer to SNA Formats for specifications 


of the RU formats. 


The table below lists each session control RU 
that pertains to session activation and deac- 


BIND 


Flow: From PLU to SLU (Expedited ) 


BIND is sent from a PLU to an SLU to activate 
a session between the LUs. The BIND indi- 
cates definite-response requested. 


The BIND carries the PLU's suggested parame- 
ters for the session. The specifications of 
the BIND parameters are based on required LU 
6.2 values,» on the PLU's 
implementation-dependent support, on the 
installation-specified values currently in 
effect for the parameters, or on the CINIT; 
depending on the particular parameter. 


The SLU uses the BIND parameters to help 
determine whether it will send back a 
+RSP(BIND), an UNBIND, or a -RSP(BIND). The 
SLU's use of UNBIND or -RSP(BIND) to reject a 
BIND is based on whether the SLU is a 
current-level or back-level node. Control 


information in either LU is updated only when > 


a positive response is returned. A success- 
ful BIND causes a half-session to be created 
at both PLU and SLU. 


If the LU receives a BIND after sending a 
BIND, and either (1) parallel sessions 
between the two LUs are not supported, or (2) 
the current number of active sessions within 
the mode-name group is 1 less than the ses- 
sion limit for that group, then a BIND race 
has occurred. The BIND race is resolved by 
comparing the network-qualified LU names in 
the BINDs. Network-qualified LU names are 
unique throughout a network; therefore, one 
will always compare greater than the other in 
the EBCDIC collating sequence of the two 
names. The LU that sent the BIND containing 
the greater of the two network-qualified LU 
names is the winner (its BIND is accepted). 
The other LU is the loser (its BIND is 
rejected). 


The comparison is made by comparing the two 
names as EBCDIC character strings» 
left-justified, and filled on the right with 
space (X'40O') characters, if necessary. 


tivation, and the page number of its 
description. 


RU Page 
BIND SESSION (BIND) 4-19 
RSP (BIND ) 4-24 
UNBIND SESSION (UNBIND) 4-27 


RSP (UNBIND ) 4-28 


Network-qualified LU names contain no leading 
or embedded space characters. 


The LU winning the BIND race sends back an 
UNBIND or a -RSP(BIND). The other LU sends 
back a +RSP(BIND), unless the BIND is not 
acceptable for other reasons, such as invalid 
format. 


The BIND and its response do not have an ERP 
type. The distinction between simple acti- 
vation and resynchronizing reactivation fol- 
lowing a failure is made after the session 
has been activated. In some cases, resync 
protocols are used; in others, end-user pro- 
tocols are invoked, see "Chapter 5.3. Presen- 
tation Services--Sync Point Services Verbs" 
in Chapter 5.3. 


The SLU does not necessarily reject the BIND 
because of any incompatibility it may have 
with the BIND parameters. Rather, if the 
BIND is otherwise acceptable (for example, 
there are no format errors and the session 
limit is not exceeded), the SLU returns a 
positive response with an extended format 
that carries the complete set of session 
parameters. The specifications for the 
parameters can match those received in the 
BIND, or they can differ, where the SLU 
chooses different options. The parameters 
for which the SLU may choose different 
options are referred to as negotiable parame- 
ters. 


The PLU receives +RSP(BIND) and checks the 
parameter specifications. If acceptable, 
they are used for the activated session. 
Otherwise, the PLU sends UNBIND. 


A description of the parameters in the BIND 
follows. 


Format: This specifies the format of the 
BIND. Only one format is defined: Format 0. 
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Type: This specifies the type of BIND. The 
type is always specified as negotiable. The 
+RSP(BIND) has the same general format as the 
BIND. The negotiable type of BIND permits 
the SLU to return a positive response in 
which the negotiable parameters may differ 
from those in the request. 


FM Profile: This specifies the FM profile to 
be used for the session. FM profile 19 is 
the only one defined for LU 6.2. The FM pro- 
file is supplemented by the FM usage parame- 
ters of the BIND. 


TS Profile: This specifies the TS profile to 
be used for the session. TS profile 7 is the 
only one defined for LU 6.2. The TS profile 
is supplemented by the TS usage parameters of 
the BIND. 


FM Usage (PLU)—-Chaining Use: This specifies 
the PLU's use of chains that it sends to the 
SLU. Multiple-RU chains is the only use 
defined for LU 6.2. Chains may consist of 
one or more RUs. The maximum-size RU that 
the PLU sends and the verbs that the trans- 
action program issues to the PLU determine 
the number of RUs that make up the chain. 


FM Usage (PLU )—Request Control Mode: This 
specifies the PLU‘'s protocol for sending 
chains. Immediate-request mode is the only 


protocol defined for LU 6.2. The PLU waits 
for a response to a definite-response chain 
before it sends another chain. 


FM Usage (PLU)—Chain Response Protocol: 

Th PLU's protocol for 
requesting responses to chains. Definite- or 
exception-response requested is the only pro- 
tocol defined. A chain indicating 
definite-response requested requires a 
response from the SLU; the response may be 
positive or negative. A chain indicating 
exception-response requested requires a 
response from the SLU only when the response 
is negative; a positive response is not 
returned. 


FM Usage (PLU)—Send End Bracket: This. spec- 
ifies that the PLU does not send EB chains. 


FM Usage (SLU)—Chaining Use: This specifies 
the SLU's use of chains that it sends to the 
PLU. Multiple-RU chains is the only use 
defined for LU 6.2. Chains may consist of 
one or more RUs. The maximum-size RU that 
the SLU sends and the verbs that the trans- 
action program issues to the SLU determine 
the number of RUs that make up the chain. 


FM Usage (SLU)—Request Control Mode: This 
specifies the SLU‘'s protocol for sending 
chains. Immediate-request mode is the only 
protocol defined for LU 6.2. The SLU waits 
for a response to a definite-response chain 
before it sends another chain. 


FM Usage (SLU)—Chain Response Protocol: 

Thi specifies the SLU's protocol for 
requesting responses to chains. Definite- or 
exception-response requested is the only pro- 
tocol defined. A chain indicating 
definite-response requested requires a 


Peer Protocols 


response from the PLU; the response may be 
positive or negative. A chain indicatinc 
exception-response requested requires 4 


response from the PLU only when the response 


is negative; a positive response is not 
returned. 
FM Usage (SLU)—Send End Bracket: This spec- 


ee 0 ee 0 Geneon 


receiving segmented BIUs on the session. BIU 
segmenting affects the specifications of the 
maximum-size RUs sent by the PLU and SLU. 
This field is set according to whether the 
segment reassembly support is specified in 
the node this LU belongs to. This support is 
installation-speci fied. 


FM Usage (Common)—FM Header Usage: This 
specifies that FM headers are used on the 
session. 


FM Usage (Common)—Bracket Usage and Reset 
on the session and that the bracket reset 
state for the session is in-bracket (INB); 
that is, the session is in the in-bracket 
state following successful activation. 


FM Usage (Common)—Bracket Termination Rule: 
This specifies that rule 1, conditional ter- 
mination, will be used on the session. The 


sender of the end-bracket (CEB) chain deter- 


mines whether the bracket is to end condi s 


tionally or unconditionally. If conditional\. 
the receiver is allowed to reject the 
end-bracket chain and thereby Keep the ses- 


sion in the in-bracket state. 


FM Usage (Common)--BIND Queuing: This speci- 
fies whether the SLU is permitted to queue 
(hold) the BIND for an indefinite period 
without sending a response. Whether the PLU 
permits the SLU to queue the BIND and delay 
its response is implementation-dependent. 


ae 


ee 


All sessions for which this LU is a PLU have —. 


the same specification for this parameter. | 
FM Usage (Common)—Normal-Flow Send/Receive 
Mode: This specifies that the send/receive 
protocol for FMD requests on the normal flow 
is half-duplex flip-flop. 


FM Usage (Common )—Recovery Responsibility: 
This specifies the responsibility for recov- 
ery from an error within the session. Sym- 
metric recovery is the only value defined for 
LU 6.2. The sender of a negative response is 
responsible for recovery, regardless. of 
whether the sender is the PLU or SLU. 


FM Usage (Common )—Contention Winner/Loser: 


This specifies whether the PLU or SLU will be | 


the contention winner for the session. The 
contention winner is the brackets first 
speaker, and the contention loser is the bid- 
der. The specification of contention winner 
or loser depends on whether the session 1s | 
parallel or single session, as indicated by, 
the PS usage parameter, Parallel Session Sup- 
port, in the BIND. 
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For a parallel session, the PLU specifies 
that it is the contention winner if, for the 
mode name, the number of active sessions for 
which the PLU is the contention winner is 
less than its maximum; otherwise, the PLU 
specifies the SLU as the contention winner. 
The PLU's maximum number of contention-winner 
sessions is determined from the last 
change-number-of-sessions protocol executed 
by the two LUs. 


For a single session, the PLU specifies that 
it is the contention winner if, for the mode 
name, the SLU is to be the contention loser; 
otherwise, the PLU specifies the SLU as the 
contention winner. For each mode name asso- 
ciated with a single-session LU, the con- 
tention winner (PLU or SLU) for the session 
is installation-speci fied. (Refer to Fig- 
ure 5.4-14 on page 5.4-24). 


FM Usage (Common)—Control Vectors Included 


Indicator: This specifies that at least one 
control vector is present in the BIND. 


FM Usage (Common)—Half-Duplex Flip-Flop 
Reset States: This specifies the half-duplex 
flip-flop reset states for the PLU and SLU 
following successful activation of the ses- 
sion. The reset states are send for the PLU 
and receive for the SLU; that is, the PLU 
sends first. 


TS Usage—Staging for Secondary TC to Primary 
TC: This specifies whether pacing. of 
normal-flow requests from the SLU to the PLU 
occurs in one stage or more than one stage. 
One-stage pacing is always specified for LU 
6.2. See "Chapter 6.2. Transmission Control" 
for details on session-level pacing. 


TS Usage—Secondary TC's Send Window Size: 


This installation-specified value is set to 
the desired receive window size of the PLU. 


TS Usage—Adaptive Session-Level Pacing: 
This specifies that the PLU supports adaptive 
session-level pacing for the session. See 
"Chapter 6.2. Transmission Control" for 
details on adaptive session-level pacing. 


TS Usage—Secondary TC's Receive Window Size: 


This installation-specified value is set to 
the desired send window size of the PLU. 


TS Usage—Maximum-Size RU Sent by SLU: If 
segment reassembly is supported, an 
installation-dependent value is put in the 
BIND for the mode name. Otherwise, this 
parameter in BIND is set by SM to a minimum 
of (1) that installation-dependent value and 
(2) path control's maximum receive size RU 


for the PLU node. 


TS Usage—Maximum-Size RU Sent by PLU: If 
segment generation 1s supported,» an 
installation-dependent value is put in the 
BIND for the mode name. Otherwise, this 
parameter in BIND is set by SM to a minimum 
of (1) that installation-dependent value and 
(2) path control's maximum send size RU for 


the PLU node. 


TS Usage—Staging for Primary TC to Secondary 
TC: This specifies whether pacing 
normal-flow requests from the PLU to the StU 
occurs in one stage or more than one stage. 
One-stage pacing is always specified for LU 
6.2. 


TS Usage—Primary TC's Send Window Size: 


the desired send window size of the PLU. 


TS Usage—Primary TC's Receive Window Size: 


This installation-dependent value is set to 
the desired receive window size of the PLU. 


PS Profile—PS Usage Format: This specifies 
the PS usage format. The basic format is the 
only PS usage format defined. 


PS Profile—LU Type: 
as the LU type. 


This specifies type-6 


PS Usage—LU Type-6 Level: This specifies 
the level of LU type-6. Level 2 is the LU 
type-6 level defined for LU 6.2. 


PS Usage—Security Manager Receive Function: 

This specifies whether the PLU supports a 
security manager for receiving a user-ID;, 
password or already-verified indication, or 
profile-ID on FMH-5S Attach commands from the 


SLU. 


PS Usage—Already Verified Indicator Accept- 
accept the User-ID Already Verified indi- 
cation on FMH-5 Attach commands from the SLU. 


PS Usage—Synchronization Level: This speci- 
fies the level of synchronization support for 
the session. One of two levels of support 
may be specified: 


1. Confirm 
2. Confirm, Sync point, and Backout 


The level of support specified for the ses- 
sion determines the synchronization levels 
that can be specified for a _ conversation 
allocated to the session. The synchroniza- 
tion level, "none" (not listed above), can be 
specified for a conversation allocated to any 
session; therefore, “none" is not explicitly 
specified for the session. 


All LU implementations support the Confirm 
level; support for Sync point and Backout is 
implementation-dependent. If the PLU imple- 
mentation supports Sync point and Backout, 
the specification of support-level 1 versus 
support-level 2 is installation-specified for 
each mode name. All sessions with the same 
mode name have the same specification for 
this parameter; however, the specification 
may differ for different mode names. See 
"Chapter 5.3. Presentation Services--Sync 
Point Services Verbs" for details about Sync 
point and Backout. 


PS Usage—Responsibility for Session Reiniti- 
ation: This specifies the responsibility for 
reinitiation of a session following a session 
outage. This parameter applies only to ses- 
sions for which parallel sessions and change 
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number of sessions (CNOS) are not supported. 
Four levels of responsibility are defined: 


1. Operator controls. 

2. Primary half-session reinitiates. 
3. Secondary half-session reinitiates. 
4. Either half-session may reinitiate. 


Operator controlled reinitiation means nei- 


ther LU will automatically attempt to reini- 
tiate the session. The particular level of 
responsibility for reinitiation of the ses- 
sion--operator controlled or otherwise--can 
be either implementation-dependent or 
installation-speci fied. 


Other events may cause a session to be acti- 
vated, independent of the = reinitiation 
responsibility. For example, if the 
resources manager has queued a request for 
allocation of a conversation, the resources 
manager will request activation of a session 
when the SM informs the resources manager 
that the current session has been deacti- 
vated. 


PS Usage—Parallel-Session Support: This 


specifies that the PLU supports parallel ses- 
sions between the PLU and SLU. 


PS Usage—Change-Number-Of-Sessions Support: 
This specifies whether the PLU and SLU sup- 
port the change-number-of-sessions (CNOS) 
protocol, which includes exchange of the 
Change Number Of Sessions GDS variable. Sup- 
port for CNOS is implementation-dependent; 
however, if parallel sessions are supported, 
CNOS is also supported. If the PLU implemen- 
tation supports CNOS, the indication of sup- 
port versus no support is 
installation-specified for each partner SLU. 
All sessions with the’ same SLU have the same 
specification for this parameter; however, 
the specification may differ for different 
SLUs. 


Cryptography Options: This specifies whether 
session-level mandatory cryptography is sup- 
ported for the session, and, if so, the 
cryptography options to be used. Support for 
session-level mandatory cryptography is 
implementation-dependent.. If the mode name 
indicates support for session-level mandatory 
cryptography, then the PLU specifies in BIND 
that it is supported; otherwise, the PLU 
specifies it is not supported. All sessions 
with the same mode name have the same spec- 
ification for this parameter; however, the 
specification may differ for different SLUs. 


The cryptography options include a length 
parameter. The PLU indicates that 
session-level cryptography is not to be used 
for the session by specifying 0O for the 
length of the cryptography options. 
Session-level mandatory cryptography is the 
only session-level cryptography defined. See 
"Sessions with Cryptography" in "Chapter 6.2. 
Transmission Control" for additional antorma= 
tion. 


Primary LU Name: This specifies the name of 
the PLU for the session. 


Peer Protocols 


This parameter is not used by SM. Instead; 
SM uses the network-qualified PLU name car; 
ried in the user data to sal the PLU t 
the SLU. 


User Data: This specifies, in a structured 
format, further parameters for the session. 


Figure 4-7 shows the format of the user data 
and the preceding length. The user-data key 
is always specified as X'00', which indicates 
structured subfields follow. 
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Figure 4-7. Format of User Data 


Each subfield includes a length and is ider 
tified by a subfield Key following th. 
length. 
included, they appear in ascending order by 
subfield number. 


The structured subfields that the PLU sends 
in BIND are: 


Key Name 

x'OO' Unformatted Data 

x'0o2' Mode Name for: 
x'O3' Session-Instance ID q 
X'0G' Network-Qualified PLU Name =, 


X'11' Random Data 


A T2.1-node implementation that contains a 
single LU and a single link connection, does 
not support parallel sessions and CNOS, does 
not support the synchronization level for 
Sync point and Backout, and does not support 
LU-LU verification may omit all User-Data 
subfields. The PLU omits all User Data sub- 
fields either by specifying 0 for the length 
of the user data, or by specifying 1 for the 
length and specifying user data consisting 
only of the user-data Key; the choice is 
implementation-dependent. 


In general, the PLU may omit one or more sub- 
fields; see the descriptions of individual 
subfields for more information. If it does, 
the entire subfield, including its length, is 


omitted. 6 


Details of each subfield follow. 
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Subfield X'00'—Unformatted Data: This 
subfield carries installation-specified 
data. Support for this subfield is 
implementation-dependent. 


Subfield X'O2'—Mode Name: Mode name 
specifies the type of service required 
for the — session. Mode names~ are 
installation-speci fied. The same mode 
names are configured at both the PLU and 
SLU for all sessions between the two LUs. 
The installation-specified configuration 
for each mode name associates that mode 
name with the set of session properties 
to be used for all sessions for that mode 
name. The particular set of session 
properties associated with a mode name is 
implementation-dependent. 


A mode name may be null; that is,» a null 
mode name is a valid mode name. When 
specifying a null mode name, the PLU may 
omit the Mode Name subfield entirely. 
Alternatively, the PLU may specify only 
the length and number for the null mode 
name,» in which case the length is 1, or 
it may specify a mode name of all space 
(X'40') characters, which is equivalent 
to a null mode name. The particular form 
that the PLU uses to represent a null 
mode name is implementation-dependent. 


A T2.1-node implementation that contains 
a single LU and a single link connection, 
and that does not support parallel ses- 
sions and CNOS, may omit the Mode Name 
subfield entirely. 


Subfield X'03'—Session-Instance Identi- 
fier: The session-instance ID is used to 
uniquely identify the session from among 
the sessions where this LU is one of the 
partners. Using the session-instance ID, 
control operators at the PLU and SLU can 
coordinate the diagnostics (traces, for 
example) or clean-up procedures for a 
specific session. The session-instance 
ID is used also during resynchronization 
of a conversation after session outage. 


The LU that is the primary LU for a given 
session generates the session-instance 
ID. The first byte of the 
session-instance ID is set to X'01' to 
indicate that a PCID portion of the 
FQPCID control vector will be used for 
session identification. 


If the SLU does not use the FQPCID con- 
trol vector (see below) for session iden- 
tification, it will use the PLU-generated 
session-instance ID subfield to create a 
unique session identifier (see Subfield 
X'03' in the RSP(BIND) for more informa- 
tion). 


Subfield X'04'--Network-Qualified PLU 
Name: The network-qualified PLU name 


allows the PLU to identify itself to the 
SLU. The network-qualified PLU name is 
installation-specified at both the PLU 
and SLU. 


An LU resolves BIND-race conditions by 
comparing the network-qualified PLU name 
it sent in the BIND with the 
network-qualified PLU name it received in 
a BIND sent by the partner LU. BIND race 
conditions are discussed in more detail 
in the first part of this description of 
the BIND. 


A T2.1-node implementation that contains 
a single LU and a single link connection, 
does not support parallel sessions and 
CNOS, does not support the synchroniza- 
tion level for Sync point and Backout, 
and does not support LU-LU verification 
may have no network-qualified PLU name. 
In this case, the PLU omits’ the 
Network-Qualified PLU Name subfield from 
the BIND. 


Subfield X'11'—Random Data: This’ sub- 
field is used when LU-LU verification is 
active. See "LU-LU Verification Data" on 
page 4-18 for more information on the 
function of random data. 


User Request Correlation: Always omitted. 


Secondary LU Name: This specifies the SLU 
name used to route the BIND to the intended 
SLU for the session. 


A T2.1-node implementation that contains a 
single LU and a single link connection, does 
not support parallel sessions and CNOS; and 
1s connected over the single link to another 
T2.1-node implementation containing a single 
LU and single link connection may omit the 


SLU 


name. The PLU omits the SLU name by 


specifying 0 for the length of the SLU name. 


Control Vectors: The following control vec- 


tors may be included in the BIND: 


Fully Qualified PCID (FQPCID) control 
vector: This 1s a unique session identi- 
fier, always set in the BIND. Its value 
1s given to SM by the session services 
component of the control point. A BIND 
that includes the FQPCID control vector 
is called an extended BIND, a BIND that 
does not include the FQPCID control vec- 
tor is considered to have come from a 
back-level node. 


Class-of-Service/Transmission-Priority 
control vector (COS/TPF): This specifies 
the class of service for the session. It 
1s included in the BIND if it is present 
in the CINIT. 
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RSP( BIND ) 


Flow: From SLU to PLU (Expedited) 


A (positive or negative) response to BIND is 
sent from an SLU to a PLU. A negative 
response is sent only when rejecting a BIND 
request that did not contain an FQPCID con- 
trol vector. (When a BIND with an FQPCID con- 
trol vector is rejected, an UNBIND is sent.) 
A -RSP(BIND) consists of sense data and the 
BIND request code; the remaining fields 
described below appear only on +RSP(BIND). 


A back-level partner LU may send BIND or 
RSP(BIND) without control vectors and without 
indicating support for adaptive pacing. The 
receive support required for such back-level 
partners is shown in the procedural logic of 
the formal description. The rest of this 
section deals only with current-level sup- 
port. 


When the SLU receives a BIND that is accepta- 
ble (for example, there are no format errors 
and the SLU's session limit is not exceeded), 
the SLU sends back a +RSP(BIND) containing 
the complete set of session parameters. The 
specifications for the parameters can match 
those received in the BIND request, or they 
can differ, where the SLU chooses different 
options. The parameters for which the SLU 
may choose different options are referred to 
as negotiable parameters. 


The specifications for the matching parame- 
ters are taken directly from the BIND. The 
specifications for the negotiable parameters 
are determined by the SLU based on its 
implementation-dependent support, on the 
installation-specified values currently in 
effect for the parameters, or on the BIND; 
depending on the particular parameter. 


The following description of the RSP(BIND) 
parameters indicates the specifications that 
are used for the session and, where applica- 
ble, how they are determined. See the 
description of the corresponding parameters 
in the BIND for details of the function and 
use of the parameters. 


Format: The SLU specifies format 0. 
Type: The SLU specifies negotiable. 


FM Profile: 


Ts Profile: 


The SLU specifies FM profile 19. 
The SLU specifies TS profile 7. 


FM Usage (PLU)—Chaining Use: 
fies multiple-RU chains. 


The SLU speci- 


FM Usage (PLU)—Request Control Mode: The 
SLU specifies immediate-request mode. 
FM Usage (PLU)—Chain Response Protocol: The 


SLU specifies definite- or exception-response 
requested. 


Peer Protocols 


FM Usage (PLU)—Send End Bracket: 


The SLU 


specifies EB is not sent. 


FM Usage (SLU)—Chaining Use: 


The SLU speci- 
fies multiple-RU chains. 


FM Usage ponw Request Control Mode: The 
SLU specifies immediate-request mode. 
FM Usage (SLU)—Chain Response Protocol: The 


SLU specifies definite- or exception-response 
requested. 


FM Usage (SLU)—Send End Bracket: The SLU 


FM Usage (Common )—HWhole BIU Required Indica- 


recelving segmented RUs on the session. This 


support is installation-speci fied. 


FM Usage (Common)—FM Header Usage: The SLU 


specifies FM headers are used. 


FM Usage (Common)—Bracket Usage and Reset 


eT EE ES 8 EE 


and the bracket reset state is in-bracket 


CINB). 


The SLU specifies rule 1, conditional eae: 
nation. 


FM Usage (Common)--BIND Queuing: This field 
1s not used for RSP(BIND) since queuing of 
RSP(BIND) is not allowed. 


FM Usage (Common)—Normal-Flow Send/Receive 
Mode: The SLU specifies hal f-duplex 
flip-flop. | 


FM Usage (Common)—Recovery Responsibility: | 
The SLU specifies symmetric responsibility. 


FM Usage (Common )—Contention Winner/Loser: 
This specification depends on whether the 
session is a parallel or single session,» as 
indicated by the PS usage parameter, Parallel 
Session Support, in the RSP(BIND). For a 
parallel session, the specification is taken 
from the BIND--the SLU accepts, and does not 
change, the specification of the LU that is 
to be the contention winner for a parallel 
session. 


For a single session, the SLU specifies that 
it is the contention winner if, for the mode 
name, the installation-defined specification 
is that the SLU is to be the contention win- 
ner; otherwise, the specification is taken 
from the BIND. 

FM Usage (Common)—Control Vectors Included 
Indicator: 
one control vector is present in_ the 
RSP(BIND). An FQPCID control vector will be 
present if it was present in the BIND. 


as 


Se 


This specifies whether at lek. 2 


Fors 


rf 


oe 


~ 
. 


Ps 


FM Usage (Common)—Half-Duplex Flip-Flop 
Reset States: The SLU specifies send for the 
PLU and receive for the SLU. 


TS Usage—Secondary TC's Send Window Size: 

If adaptive pacing is supported by both this 
LU and the partner LU then this parameter is 
set to 0. The initial value of Secondary 
Send Window Size will be 1 when session traf- 
fic first starts flowing. The value of this 
parameter may change while the session is 
active. 


If adaptive pacing is not supported by both 
ends of the session, then this value is taken 
from the BIND, as follows: If the BIND spec- 
ifies one-stage pacing from the SLU to the 
PLU, this specification is taken from the 
Primary TC's Receive Window Size field; oth- 
erwise, this specification is taken directly 
from the Secondary TC's Send Window Size 
field. 


TS Usage—Adaptive Session-Level Pacing: 
Copied from the BIND. That is, if adaptive 
pacing is requested, it will be used on this 
session. If not requested, fixed pacing will 
be used. 


TS Usage—Secondary TC's Receive Window Size: 
If adaptive pacing 1s supported by both this 
LU and the partner LU, then this parameter is 
set to 0. The initial value of Secondary 
Receive Window Size will be 1 when session 
traffic first starts flowing. The value of 
this parameter may change while the session 


is active. 


If adaptive pacing is not supported by both 
ends of the session, then this value is based 
on the BIND’ for the session and =e an 
installation-specified value associated with 
the mode name (this value is always greater 
than 0, as enforced by the control operator 
component of the LU), as follows: 


e If the BIND for the session specifies a 
secondary TC's receive window size of 0, 
this specification is taken from | the 
installation-specified value. 


e If BIND specifies a window size other 
than 0, this specification is taken from 
the minimum of the value in BIND and the 
installation-specified value. 


TS Usage—Maximum-Size RU Sent by SLU: The 
upper and lower bounds are set to 
installation-specified values. If the SLU's 
node does not support the segment generation 
or the PLU does not support segment regener- 
ation, then SLU resets the upper bound to the 
minimum of the current upper bound and the 
path control's maximum RU size. The SLU 
specifies a value between a lower bound and 
the upper bound, as follows: 


e If the value specified in the BIND is 
between the lower and upper bounds, the 
value in the RSP(BIND) is taken from the 
BIND. 


e If the value specified in BIND is less 
than the lower bound, the SLU sets the 
value in the RSP(BIND) to the lower 
bound. 


e If the value specified in BIND is greater 
than the upper bound, the SLU sets the 
value in the RSP(BIND) to the upper 
bound. 


TS Usage—Maximum-Size RU Sent by PLU: The 
SLU determines a value between a lower bound 
and an upper bound, in the same manner 
described above for the maximum-size RU sent 
by the SLU, except that when modifying an 
upper bound, it takes into account only the 
PLU's capability to reassemble (rather than 
to generate) segments. 


TS Usage—Staging for Primary TC to Secondary 


TS Usage—Primary TC's Send Window Size: If 
and the partner LU, then this parameter is 
set to 0. The initial value of Primary Send 
Window Size will be 1 when session traffic 
first starts flowing. The value of this 
parameter may change while the session is 
active. 


If adaptive pacing is not supported by both 
ends of the session, then this value is taken 
from the BIND, as follows: If the BIND spec- 
ifies one-stage pacing from the PLU to the 
SLU, this specification is taken from the 
Secondary TC's Receive Window Size field; 
otherwise, this specification is taken 
directly from the Primary TC's Send Window 
Size field. 


TS Usage—Primary TC's Receive Window Size: 
LU and the partner LU, then this parameter is 
set to 0. The initial value of Primary 
Receive Window Size will be 1 when session 
traffic first starts flowing. The value of 
this parameter may change while the session 
is active. 


If adaptive session pacing is not supported 
by both ends of the session, then this value 
is taken from the BIND. 


PS Profile—PS Usage Format: The SLU speci- 
fies basic format. 


PS Profile—LU Type: The SLU specifies LU 
type-6. 


PS Usage—LU Type-6 Level: The SLU specifies 
level 2. 


PS Usage—Security Manager Receive Function: 
rity manager for receiving a user-ID, pass- 
word or already-verified indication, and 
profile-ID on FMH-5 Attach commands from the 
PLU. 


PS Usage—Already Verified Indicator Accept- 
ance: The SLU specifies whether it will 
accept the User-ID Already Verified indi- 
cation on FMH-5 Attach commands from the PLU. 
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PS Usage—Synchronization Level: The SLU 
specifies the s ronization level for the 
session, as follows: 


e If a session between the SLU and PLU is 
already active for the mode name, the SLU 
specifies the same level of support as 
specified for the active session. 


e If no sessions between the SLU and PLU 
are active for the mode name and the BIND 
specifies Confirm, Syne point, and Back- 
out, the SLU specifies the 
installation-specified value associated 
with the mode name for the session. 


e If no sessions between the SLU and PLU 
are active for the mode name and the BIND 
specifies Confirm, the SLU specifies Con- 
firm. 


PS Usage—Responsibility for Session Reiniti- 


ation: The SLU specifies the responsibility 


for reinitiation 


based on the 
installation-specified responsibility and on 
the specification in the BIND. This parame- 
ter applies only to sessions for which paral- 
lel sessions and change number of sessions 
(CNOS) are not supported. : 


The matrix in Figure 4-8 shows how the SLU 
derives the specification for the RSP(BIND). 
The row headings of the matrix give the 
installation-specified responsibility and the 
column headings give the responsibility spec- 
ified in the BIND. The cells of the matrix 
give the responsibility that the SLU speci- 
fies in the RSP(BIND). 


Row headings indicate 
installation-specified responsibility. 


Column headings indicate 
responsibility specified in BIND. 


- Cells indicate responsibility 
specified in RSP(BIND). 


ator mary ondary 


Oper- Oper- Oper- Oper- 
ator ator .| ator ator 
Oper- | Pri- Either] Pri- 
ator mary mary 
Oper- {| Either] Sec- Sec- 
ator ondary| ondary 
Oper- | Pri- Sec- Either 
ator mary ondary 


Figure 4-8. 
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PS Usage—Parallel~Session Support: 
specifies parallel-session support for the 


session, as follows: 


e If a session between the SLU and PLU is 
already active, the SLU specifies the 
same support as specified for the active 
session. 


e If no sessions between the SLU and PLU 
are active and the BIND specifies paral- 
lel sessions are supported, the SLU spec- 
ifies the installation-specified value 
associated with the PLU. 


¢ If no sessions between the SLU and PLU 
are active and the BIND specifies paral- 
lel sessions are not supported, the SLU 
specifies parallel sessions are not sup- 
ported. 


PS Usage—Change-Number-Of-Sessions Support: 


The SLU specifies support for the use of 
change-number-of-sessions (CNOS) protocols, 


as follows: 


e¢ If a session between the SLU and PLU is 
already active, the SLU specifies the 
same support as specified for the active 
session. 


¢ If no sessions between the SLU and PLU 
are active and the BIND specifies CNOS is 
supported, the SLU specifies the 
installation-specified value associated 
with the PLU. 


e If no sessions between the SLU and PLU 
are active and the BIND specifies CNOS is 
not supported, the SLU specifies CNOS is 
not supported. 


Cryptography Options: Taken from the BIND. 


Primary LU Name: Always omitted. 

User Data: The SLU specifies further parame- 
ters for the session by means of the User 
Data structured subfields. If the SLU 
receives a BIND containing a subfield it does 
not recognize, it ignores the subfield and 
does not send it in the RSP(BIND). 


The User Data subfields that the SLU sends in 
the RSP(BIND) are: 


Number 


Name 
- ¥'00' Unformatted Data 
x'O02' Mode Name 
x'O3' Session-Instance ID 
x'O5' Network-Qualified SLU Name 
x'11' Random Data 
X'12' Enciphered Data 


A T2.1-node implementation that contains a 
single LU and a single link connection, does 
not support parallel sessions and CNOS, does 
not support the synchronization level for 
Sync point and Backout, and does not support 
LU-LU verification may omit all User Data 
subfields. 


The SLU 
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In general, the SLU may omit one or more sub- 
fields; see the descriptions of individual 
subfields for more information. If it does, 
the entire subfield, including its length, is 
omitted. 


Details of each subfield follow. 


® Subfield X'00'—Unformatted Data: This 
subfield carries installation-speci fied 
data. Support for this subfield is 
implementation-dependent. 


e Subfield X'02'—Mode Name: Taken from 
the BIND, if present there. Otherwise, a 
Mode Name subfield consisting of eight 
space (X‘'40) characters will be set in 
the RSP(BIND). 


® Subfield X'03'--Session Instance Identi- 
fier: Lf this subfield was omitted from 
the BIND, it will also be omitted from 
the RSP(BIND). If it was present in the 
BIND then SLU sets it in the RSP(BIND) as 
follows: 


- If the first byte of this subfield in 
the BIND is set to X'01' the SLU 
returns the abbreviated session 
instance identifier (PCID portion of 
the FQPCID) with the first byte set 
to X'02'. That will indicate that 
both PLU and SLU will use the FQPCID 
control vector to uniquely identify 
the session. 


- Otherwise (the first byte of this 
subfield in the RSP(BIND) is set to 
X'00'), the value is taken from the 
BIND, except that the SLU changes the 
value of the first byte, if neces- 
sary» to make the session-instance ID 
unique. The SLU sets the first byte 
to X'FO' if the PLU's network quali- 
fied LU name is greater than its own. 
Otherwise, it sets the first byte to 
x‘OO'. 


Before sending a RSP(BIND), the SLU 
checks that the negotiated session iden- 
tifier is different from that of all 
active sessions in which this SLU partic- 
ipates. If the identifier is not unique, 
the BIND is rejected. 


UNBIND 


Flow: From LU to LU (Expedited) 


UNBIND requests the partner LU to deactivate 
the —s- session. The UNBIND indicates 
definite-response requested. After SM sends 
an UNBIND, it does not Keep any information 
pertaining to the session. 


A description of parameters in the UNBIND 
follows. 


e Subfield = X'05'--Network-Qualified SLU 
Name: The network-qualified SLU name 
allows the SLU to confirm its identify to 
the PLU. The network-qualified SLU net- 
work name is installation-specified at 
both the SLU and PLU. 


All T2.1-node products can receive a BIND 
with the Network-Qualified PLU Name sub- 
field omitted. If the SLU receives such 
a BIND, it uses aeunique' default 
network-qualified PLU name in order to 
locally identify the PLU. 


A T2.1-node implementation that contains 
a single LU and a single link connection, 
does not support parallel sessions and 
CNOS, does not support the synchroniza- 
tion level for Sync point and Backout, 
and does not support LU-LU verification 
may have no network-qualified SLU name. 
In this case, the SLU omits’ the 
Network-Qualified SLU Name subfield from 
the RSP(BIND). 


@ Subfield X'11'—Random Data: This sub- 
field is used when LU-LU verification is 
active. See "LU-LU Verification Data" on 
page 4-18 for more information on the 
function of random data. 


® Subfield X'12'—Enciphered Data: When 
the primary LU receives the RSP(BIND), it 
compares the received enciphered data 
with its copy of the enciphered data that 
it has enciphered using the same random 
data, its copy of the LU-LU password, and 
the DES algorithm. If they are identi- 
cal, the primary LU has verified that the 
SLU has the correct LU-LU password. 


User Request Correlation Field: Copied from 
the BIND. 


Secondary LU Name: Always omitted. 


Control Vectors: The following control vec- 
tors may be included in the RSP(BIND): 


e Fully Qualified PCID (FQPCID) control 
vector: Copied from the BIND, if pres- 
ent; otherwise, not included in the 
RSP( BIND). 


Type: This specifies the type of session 
deactivation requested. The LU specifies 
normal deactivation when it is deactivating 
the session normally, that is, not as a 
result of an error condition. In this case, 
the two LUs stop all activity on the session 
prior to deactivating it. Activity is 
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stopped by exchanging BIS requests. See 
“Chapter 6.1. Data Flow Control" for a 
description of the BIS request, and “Chapter 
3. LU Resources Manager" for details of its 
use. | 


UNBIND(Cleanup) is sent in response to a BIND 
that was not accepted. 


The other types of session deactivation are 
- associated with error conditions. : 


Sense Data: Identifies the reason for the 
UNBIND. This field is included in the UNBIND 
-if the UNBIND type is X'FE' (Session Fail- 
ure). 


Control Vectors: The following control vec- 
tors may be included in the UNBIND: 


e FQPCID control vector: When SM sends an 
UNBIND, ait includes an FQPCID control 
vector except when it received a BIND or 
a RSP(BIND) for the session without it. 
SM is always prepared to receive an 
UNBIND without an FQPCID control vector 
if a sender is a back-level LU. 


e Extended Sense Data (ESD) control vector: 
This control vector is included if and 
only if the FQPCID control vector is 
included and the UNBIND type is not X'01' 
(Normal End of Session). 


NOTE 1: The general architecture allows for 
some other UNBIND types not to use the ESD 
control vector. However, the session manager 
generates only three different UNBIND types: 


RSP ( UNBIND } 


Flow: From LU to LU (Expedited) 


The LU receiving the UNBIND tries to send 
back a +RSP(UNBIND). If SM can correlate an 
UNBIND to one of its active or pending-active 
sessions, it uses a buffer it pre-reserved at 
session activation for the RSP(UNBIND). If 
SM cannot correlate an UNBIND to one of its 
active or pending-active sessions, it asks 
the BM for a demand buffer to be used for the 
RSP(UNBIND }. If such a buffer cannot be 
obtained, RSP(UNBIND) is not sent. 


SM AND BUFFER MANAGEMENT 


When SM gets a request to activate a session 
(from either RM or the partner LU), it asks 
the buffer manager (BM) to reserve the buff- 
ers needed for the session. 


e® When SM is initialized, it asks the BM to 
reserve a permanent buffer pool. This 
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Normal , Cleanup» and Invalid Session 
Paramenters. Out of those three, Normal is 
the only one that does not require an ESD 
control vector when an FQPCID control vector 
is included. 


NOTE 2: Although SM generates only three 
UNBIND types, it is able to receive an UNBIND 
of any defined type. See SNA Formats for a 
list of all possible UNBIND types. 


NOTE 3: RM and SS need to be informed of the 
reason for the session deactivation. Since 
only UNBIND type X'FE' carries sense data in 
the RU, SM sets a default value for the other 
UNBIND types. The default sense data are 
assumed, as follows: 


UNBIND TYPE SENSE DATA 

X'07' VR_INOP X'80200001' 
X'08' ROUTE_EXT_INOP X'80200004' 
X'09' HIERARCHICAL_RESET X'80030001' 
X'OA' SSCP_GONE X'O8A00001' 
X'OB' VR_DEACTIVATED X'80200003 ' 
X'0C' LU_FAIL_UNRECOV X'80030003 ' 
X'OE' LU_FAIL_RECOV X'80030006' 


X'OF* CLEANUP 


X'11' GW_NODE_CLEANUP 


The LU sends a -RSP(UNBIND) if the format of 
the UNBIND is in error. Otherwise, the LU 
sends back a +RSP(UNBIND), even if it has no 
HS to which it can correlate the UNBIND. A 
-RSP(UNBIND) includes sense data indicating 
the format error. 


buffer pool is shared by all HS processes 
created by SM. HS uses the buffers in 
the pool to send responses, 
requests, and IPM acknowledgments. 


e When SM creates a new HS (part of session 
activation), it requests BM to increase 


eo 


a 


4 
See ° 


’ . 
Nea eae? 


*%'O8A00002' a 


X'08A00003' \_ | 


ae 


—— 
.S 
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the number of buffers in the pool; thus 
as the number of half-sessions using the 
buffer pool increases, the number of 
buffers available increases. When SM 
destroys a HS, it requests BM to decrease 
the number of buffers in the pool. 


When SM sends a BIND, it asks the BM for 
a demand buffer, which is used to build 
the BIND. When SM receives a BIND, it 
always gets it in a permanent buffer that 
can be reused to send the UNBIND or 
-RSP( BIND). When SM receives a 
RSP(BIND), an UNBIND, or a RSP(UNBIND), 
it gets it in a demand buffer, which is 
always freed and not reused by SM. 


After session parameters are negotiated, 
SM reserves dynamic and limited buffer 
pools that will be used by HS for the 
session. The dynamic buffer pool is used 
for receive pacing buffers, while the 
limited buffer pool is used to send 
normal-flow requests. 


e At session activation, SM reserves a 
buffer that will be used when an UNBIND 
or a RSP(UNBIND) has to be sent. By pre- 
reserving this buffer, SM can always 
issue an UNBIND or RSP(UNBIND), even if 
BM runs out of other buffer space. 


e At session deactivation time SM requests 
BM to decrease the number of buffers in 
the permanent buffer pool. 


e When SM destroys a HS, the dynamic and 
limited buffer pools that were estab- 
lished at session activation time are 
automatically destroyed. 


If any of the required buffers cannot be 
reserved, SM does not proceed with session 
activation and sends’ either an_e ACTI- 
VATE_SESSION_RSP( negative) record to RM, or 
an UNBIND or -RSP(BIND) with type Cleanup to 
the partner LU, depending upon who requested 
the session. For more details on BM, see 
"Appendix B. Buffer Manager". 
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SM FLOWS 


4-30 


This section shows sequence flows that can 
occur between SM and other components of the 
LU, the node's control point, the node's 
buffer manager, and other LUs. These flows 
illustrate some examples of session initi- 
ation and termination. The flows illustrate 
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the records listed in "SM Protocol Bounda- 


ries" on page 4-4. 


See "Component Interactions and Sequence 
Flows" on page 2-48 for a description of the 
conventions used in the flows. 


C) 


* 


(Receive and process signals) 


Figure 4-9. SM Initialization 


The following notes correspond to the numbers 3. SM sends RM_CREATED record to inform NOF 
in Figure 4-9. that the RM has been created. 
4. SM reserves a permanent buffer pool for 
{> 1. NOF creates SM during node initializa- its own use and to be shared by all HSs 
: tion. that it creates; see "SM and Buffer Man- 
Ry agement" on page 4-28 for details. 


2. SM creates RM. 
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LU cP 
| ee eae eee 
RM SM HS BM SS ASM PC LU 
ee @ 
ACTIVATE_ ; : : 
SESSION z . ASSIGN_PCID : : 


1 o_o 0 


‘ . ASSIGN_PCID_RSP | 
° o< 
‘ | . INIT_SIGNAL ‘ 
2 . >o 


: ; -(CP proceeds with ay ; 
. CINIT_SIGNAL _ . session activation. ) ‘ ; 


SSS 


‘ ASSIGN_LFSID . , ; 
3 ‘ >o . 
; ; ASSIGN_LFSID_RSP ‘ | 
o< 


ADJUST_BUFFER_POOL(permanent buffer pool ID) 


+RSP( BIND ) 


CREATE_BUF_POOL( dynamic, limited) 


; | INIT_HS . CRV 
8  ACTIVATE_ >o 


SESSION. . INIT_HS_ : ; : 
RSP( +) . RSP( +4) +RSP(CRV) ; 
o< OX a a 


lL, 


Figure 4-10. Session Initiation by Local LU 


The following notes correspond to the numbers 3. 
in Figure 4-10. 


1. RM sends ACTIVATE_SESSION to SM request- 
ing a session be activated with the spec- 4. 
ified partner LU; RM expects a response. 
SM requests SS to create an FQPCID, which 
will uniquely identify the session. SM 
will verify that this PCID does not col- 
lide with a PCID for any of its active or 
pending-active sessions. (See Fig- 
ure 4-11 on page 4-33 for collision han- 5. 
dling logic. ) 


2. SM sends an INIT_SIGNAL record to SS 
requesting the CP's assistance in acti- 
vating the session. SS, if successful, 
returns a CINIT_SIGNAL, which contains a re 
path control ID, the maximum BTU size, 
segmenting capabilities, and (if mode 
name to COS/TPF mapping is supported) a 
COS/TPF control vector. SS, if unsuc- 
cessful, returns an INIT_SIGNAL_NEG_RSP 
(not shown) indicating a failure (see SNA 


Type 2.1 Node Reference for details). 8. 
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So 


SM sends an ASSIGN_LFSID to ASM request- 
ing an LFSID for the session. ASM 
returns an ASSIGN_LFSID_RSP record, which 
contains the requested LFSID. 


SM increases the number of buffers in the 
permanent buffer pool. All HSs created 
by this SM share this buffer pool. HS 
uses these buffers for sending responses,» 
expedited requests, and IPM acknowledg- 
ments. 


SM creates an HS for the session. 


SM sends the BIND to ASM, which ASM will 
send to the partner LU; a RSP(BIND) is 
returned to SM from ASM. 


SM obtains a dynamic buffer pool, and a 
limited buffer pool for HS when it Knows 
the maximum RU sizes from the RSP(BIND). 
HS uses the dynamic buffers for receive 
pacing buffers, while the limited buffers 
are used to send normal-flow requests. 


SM sends an INIT_HS record to the HS it 
created. This record gives HS all the 
session information it needs to begin to 


C > 


perform its functions. This information 

rte includes the values of the negotiated 
< { session parameters, and buffer pool IDs 
er (returned by buffer manager on the CRE- 
ATE_BUF_POOL calls). If cryptography is 

used, the LUs exchange CRV and its 


response. The HS sends an INIT_HS_RSP to 
SM to indicate successful initialization. 
SM then sends an ACTIVATE_SESSION_RSP in 
response to the original ACTIVATE_SESSION 
record. This record indicates whether SM 
was able to satisfy RM's request. 


LU cp 
ee re ee eg ere ee fee Fe Ue 
RM SM HS BM ss ASM 
ACTIVATE__ ‘ ; , é 
SESSION A - ASSIGN_PCID ‘ - 
1 Oe mena >O ‘ 
. ASSIGN _PCID_RSP | : 
o< ° 
(PCID collision detected) ‘ F : 
| . ASSIGN_PCID : : 
ened >o : 
\ . : . ASSIGN_PCID_RSP | 
C ye . o< ° 
| .  INIT_SIGNAL ; 
>O . 
2 ; ‘ : . (Session initiation proceeds as in 


Figure 4-10 on page 4-32.) 


Figure 4-11. Session Initiation by Local LU: PCID Collision Detected 


= The following notes correspond to the numbers 
4 in Figure 4-11. 


1. RM sends an ACTIVATE_SESSION record to 
SM. SM sends an ASSIGN _PCID to SS 
requesting a unique FQPCID be assigned 
for the session. ss sends an 
ASSIGN_PCID_RSP to SM, which contains the 
FQPCID that was assigned. SM compares 


the FQPCID with the FQPCIDs of all its 
active and pending-active sessions. In 
this case, a collision is found. SM 
sends another ASSIGN_PCID to SS», indicat- 
ing that an FQPCID collision was found. 
This continues until SS_ returns= an 
ASSIGN_PCID_RSP with an FQPCID that is 
unique. 


Session initiation continues normally. 
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BM 
° - BIND(FQPCID) 


ADJUST_BUFFER:-_POOL( permanent buffer pool ID) 


>oO 


| ‘ - +RSPC(BIND(FQPCID )) 


CRV 


-INIT_HS_ | . +RSP(CRV ) . . 
- RSP(+) oO 


o< ‘ 


. | - SESSST_SIGNAL : 
SESSION_ >o 
ACTIVATED | . : ; 
o< 


Figure 4-12. Session Activation by Partner LU: BIND(FQPCID) Is Received 


The following notes correspond to the numbers session information it needs to begin to 
in Figure 4-12. perform its functions. This information _- 
includes the values of the negotiated | 
session parameters, and buffer pool IDs’. 
1. SM receives BIND via ASM; the BIND of the buffers obtained from BM. - 
includes an FQPCID control vector. 
6. If cryptography is used, the LUs exchange 


2. SM adjusts (increases) the number of CRV and its response. 
buffers in the permanent buffer pool. 
The buffers in this pool are shared by 7. SM receives a INIT_HS_RSP from HS indi- 
all HSs created by SM. | cating that HS was successfully initial- 
ized. 


3. SM creates the HS for the session. 
| 8. SM sends a SESSST_SIGNAL to notify SS 


4. SM send the RSP(BIND) to ASM. Since the that the session has been successfully S 
BIND included the FQPCID control vector, activated at the request of the partner 
the FQPCID will also be included in the LU. ee 
RSP(BIND). The FQPCID is used by the 9. SM sends SESSION_ACTIVATED to notify RM 
partner LU to correlate the BIND and that the session has been successfully 
RSP(BIND). activated at the request of the partner 
LU. 


5. SM sends an INIT_HS record to the HS it 
created. This record gives HS all the 


C) 


—” 
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LU 
SM BM 
o< 
.  ASSIGN_PCID ‘ 
>O 
: . ASSIGN_PCID_RSP | 
o< 


ADJUST_BUFFER_POOL( permanent buffer pool ID) 


BIND( without FQPCID control vector ) 


- #+#RSP(BIND( without FQPCID control vector) . 


CRV 


+RSP(CRV } 


o< 


‘ | ; SESSST_SIGNAL ‘ 
SESSION _ >o 
ACTIVATED | ‘ P : 
o< 


o_o ———_>0 


Figure 4-13. Session Activation by Partner LU: BIND Is Received 


The following notes correspond to the numbers 6. 
in Figure 4-13. 


1. SM receives BIND from a back-level part- 
ner LU; the BIND does not include an 
FQPCID control- vector. 


2. Since no FQPCID was in the BIND, SM sends re 
ASSIGN_PCID to SS requesting an FQPCID to 
be assigned to this session. SS returns 
the FQPCID in the ASSIGN_PCID_RSP record. 8. 


3. SM adjusts (increases) the number of 
buffers in the permanent buffer pool that 
is shared by all HSs created by SM. 


G4. SM creates the HS for the session. 


5. SM sends the RSP(BIND) to the partner LU. 
Since the BIND did not contain an FQPCID, 
the FQPCID 1s not appended to the 
RSP(BIND). | 


SM sends an INIT_HS record to the HS it 
created. This record gives HS all the 
session information it needs to begin to 
perform its functions. This information 
includes the values of the negotiated 
session parameters, and buffer pool IDs 
of the buffers obtained from BM. 


If cryptography is used, the LUs exchange 
CRV and its response. 


SM sends a SESSST_SIGNAL to notify SS 
that the session has been successfully 
activated at the request of the partner 
LU. 


SM sends SESSION_ACTIVATED to notify RM 
that the session has been successfully 
activated at the request of the partner 
LU. 
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RM 


DEACTIVATE_. 
SESSION 
o> 0 


| r : UNBIND ; é : é 
| : SESSEND_SIGNAL ‘ 
>o 


e 
/ 


OOO 0 


ADJUST_BUFFER_POOL(permanent buffer pool ID) 


4-14. Session Deactivation by Local LU 


The following notes correspond to the numbers it does not wait for the RSP(UNBIND). SM 
in Figure 4-14. sends a SESSEND_SIGNAL record to notify 
~ §S that the session is no longer active. 

1. RM sends DEACTIVATE_SESSION record to SM 3. SM adjusts (decreases) the number of 
requesting that the session be deacti- buffers in the permanent buffer pool; the 
vated. dynamic and limited buffer pools are 
automatically destroyed when the HS is 

2. SM sends UNBIND to the partner LU. At destroyed 


this point, SM deactivates the session; 


: : . UNBIND ; 
SSS SO 


o< 


Figure 4-15. Session Deactivation by Partner LU 


The following notes correspond to the numbers 3. SM sends SESSEND_SIGNAL to notify SS that 
in Figure 4-15. the session has ended. 


4. SM adjusts) (decreases) the number of 


1. SM receives UNBIND from the partner LU buffers in the permanent buffer pool; the 
and returns a RSP(UNBIND). . dynamic and limited buffer pools are 
automatically destroyed when the HS is 

2. SM sends SESSION DEACTIVATED to notify RM destroyed. 


that the session is deactivated. 
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BM 


; (session traffic) 


SESSION_ROUTE_INOP 


SESSION_ o< 


DEACTIVATED] ‘ 
o< 


| ; SESSEND_SIGNAL : 
>o 


ADJUST_BUFFER_POOL(permanent buffer pool ID) 


Figure 4-16. SM receives SESSION_ROUTE_INOP While a Session Is Active 


C) The following notes correspond to the numbers 3. SM sends SESSEND_SIGNAL to notify SS that 
. in Figure 4-16. the session has ended. 


G4. SM adjusts (decreases) the number of 


1. ASM sends SESSION_ROUTE_INOP to SM indi- buffers in the permanent buffer pool; the 
cating that a route is no longer active, dynamic and limited buffer pools will be 
and all sessions using this route need to automatically destroyed when the HS is 
be deactivated. | destroyed. SM destroys the HS for the 

session. 


2. For each of this SM's active sessions 
that use the affected route, SM sends 
SESSION_DEACTIVATED to notify RM that the 


= session 1s deactivated. 
7 


RM 


ACTIVATE_ 
SESSION 
oo 20 


(Initiation sequence proceeds as in Figure 4-10 on page 4-32. ) 
BIND ; : ; 
a —— OO 
A SESSION_ROUTE_INOP 


ACTIVATE_ 
SESSION_ 
RSP(-) 

o<-————"-0 ° 


| - SESSEND_SIGNAL Z 
>O 


l ADJUST_BUFFER_POOL( permanent buffer pool ID) 


Figure 4-17. SM Receives SESSION_ROUTE_INOP While a Session Is Waiting Activation 


The following notes correspond to the numbers SM a SESSION_ROUTE_INOP, informing SM 
~ in Figure 4-17. that the session cannot be activated. 
& 2. SM returns a negative ACTI- 
1. After SM has sent out the BIND, and VATE_SESSION_RSP informing RM that the 

before a RSP(BIND) 1s returned, ASM sends requested session could not be activated. 
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SM then cleans up by sending a 3. 
SESSEND_SIGNAL to inform SS that the ses- 
sion initiation is being stopped. 


ACTIVATE. . 
SESSION... 


(Initiation sequence procedes as in 
° . BIND 
© eee 


ACTIVATE_ o< 


SESSION_ 
RSP(-) | 
o< < : : 
| | . SESSEND_SIGNAL ; 
>o 


ADJUST_BUFFER_POOL( permanent buffer pool ID) 


SESSION_ROUTE_INOP 


( ignored ) 


Figure 4-10 on page 4-32.) — 


SM adjusts (decreases) the number of 
buffers in the permanent buffer pool. 


70 


Figure 4-18. SM Receives SESSION_ROUTE_INOP While a Session Is Waiting Activation, Resulting in 
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BIND Crossing SESSION_ROUTE_INOP 


The following notes correspond to the numbers 
in Figure 4-18. 


‘1. ASM sends a SESSION_ROUTE_INOP to SM; 
this record is sent to all SMs in the 
node by ASM whenever a link is brought 
down. 


2. SM receives an ACTIVATE_SESSION record 
and begins the initiation sequence. A 
BIND for the session is sent to ASM. 


3. SM receives the SESSION_ROUTE_INOP that 
was sent in step 1. SM brings down all 
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currently active and pending-active ses- 
sions that use the affected route. In 
this case, this includes the session that 
is currently being activated. 

SM receives a SESSION_ROUTE_INOP in 
response to the BIND it sent. The corre- 
sponding session is no longer 
pending-active, since the previous SES- 
SION_ROUTE_INOP forced the session to be 
deactivated; thus, the SESSION_ROUTE_INOP 
is ignored. 


C> 
a 


C) 


RM 

5 : : . SESSION_ROUTE_INOP : 
ACTIVATE_ . : oO 
SESSION : . ASSIGN_PCID : : 
© came aaa a ca ee eee is ° | * 
. ASSIGN_PCID_RSP 


o< 


| ;  INIT_SIGNAL : 


o< .(CP proceeds with 
(ignored ) : ; . session activation, and 
d - a route is successfully 
CINIT_SIGNAL . reactivated. ) 
CSS 
(Session activation proceeds as in Figure 4-10 on page 4-32. ) 


Figure 4-19. SM Receives SESSION_ROUTE_INOP While a Session Is Waiting Activation, Resulting in an 
INIT_SIGNAL Crossing SESSION_ROUTE_INOP 


The following notes correspond to the numbers sions are active or pending active (a 
in Figure 4-19. session is not pending-active until a 
BIND has been sent) that use the affected 
route, so the SESSION_ROUTE_INOP is 
1. ASM sends a SESSION_ROUTE_INOP for a cur- ignored. 
rently active session. 
As SM is processing the SES- 


2. SM receives an ACTIVATE_SESSION record SION_ROUTE_INOP, the CP proceeds with the 
and begins the session initiation session activation. During the acti- 


sequence. SM sends an INIT_SIGNAL to SS. vation, the CP is able to reactivate the 
| route that was down. 
3. After SM sends the INIT_SIGNAL to SS, and 


before SS returns a CINIT_SIGNAL, SM 4. SS sends a CINIT_SIGNAL to SM in response 
receives the SESSION_ROUTE_INOP that was to the preceding INIT_SIGNAL. 
sent in step 1. In this case, no ses- 
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Figure 4-20. 
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RM 


ACTIVATE_ . ; 
SESSION ; 


BM 


. ASSIGN_PCID 


oa eS 


p . ASSIGN_PCID_RSP | 

o< 

| .  INIT_SIGNAL ; 
>Oo 


ACTIVATE_ 


SESSION __ : : 
RSP(-} ‘ : 
o< 


| . SESSEND_SIGNAL 
> 


CINIT_SIGNAL 


| . ASSIGN_LFSID : : 

mae) 
; ASSIGN_LFSID_RSP( sense data) | 
o< 


Session Activation by Local LU: 


The following notes correspond to the numbers 
in Figure 4-20. 


SNA LU 6.2 Reference: 


RM sends SM an ACTIVATE_SESSION. SM 
sends an ASSIGN_PCID to SS; SS returns an 
ASSIGN_PCID_RSP to SM that contains the 
requested PCID. ° SM then’ sends an 
INIT_SIGNAL to SS; the CP determines 
Where the partner LU is and returns a 
CINIT_SIGNAL or an_ INIT_SIGNAL_NEG_RSP 
(not shown) as described for Figure 4-10 
on page 4-32. SM then sends’ an 


Peer Protocols 


OQ 


Oo 


. (CP proceeds with 


session initiation. } 


LFSID Assignment Failed 


ASSIGN_LFSID to SS requesting an LFSID 
for the session. 


SM receives an ASSIGN_LFSID_RSP that con- 
tains sense data indicating why an LFSID 
could not be assigned. 


SM sends a negative ASSIGN_SESSION_RSP to 
inform RM that the session could not be 
activated. 


SM sends a SESSEND_SIGNAL to inform SS 
that the session initiation failed. 


au ar 


RM 


ACTIVATE_ 
SESSION 
oo" 70 ° ° ° ° 
(Initiation sequence proceeds as in Figure 4-10 on page 4-32.) 
z BIND : . : 
> OOOO eee 0 


; UNBIND - . 
Oe if 


| RSP(UNBIND ) ; 
ACTIVATE_ : 


SESSION_ . : : 
RSP(- ) ; ‘ : 
o< : . 


| - SESSEND_SIGNAL . 
>o 


ADJUST_BUFFER_POOL( permanent buffer pool ID) 


Figure 4-21. Session Activation by Local LU: BIND Is Rejected with UNBIND 


The following notes correspond to the numbers 3. SM sends a RSP(UNBIND) to the partner LU. 
in Figure 4-21. 

4. SM sends a negative ACTIVATE_SESSION_RSP 

to inform RM that the session could not 


\ 1. SM receives an ACTIVATE_SESSION record be activated. SM then cleans up the ses- 
and begins the initiation sequence by sion by sending a SESSEND_SIGNAL to 
sending BIND to the partner LU. inform SS that the session activation 
failed, adjusts (decreases) the number of 

2. SM receives an UNBIND from the partner LU | buffers in the permanent buffer pool. 


rejecting the BIND. 


RM 


ACTIVATE_ 

SESSION 

o_o ; . ‘ 

(Initiation sequence proceeds as in Figure 4-10 on page 4-32.) 

° ‘ BIND - < r 
or OOOO —" eee OO 

‘ -RSP( BIND } : 

o< 

PC_HS_DISCONNECT 


ACTIVATE __ 
SESSION_ . ° 
RSP(-) ‘ . 
o< 


SESSEND_SIGNAL 


Figure 4-22. Session Activation by Local LU: BIND Is Rejected with -RSP(BIND). 
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The following notes correspond to the numbers 3. SM sends a PC_HS_DISCONNECT instructing 


in Figure 4-22. ASM to free the LFSID. * 
G4. SM sends a negative ACTIVATE_SESSION_RSP \__~ 
1. SM receives an ACTIVATE_SESSION record to inform RM that the session could not 
and begins the initiation by sending BIND be activated. SM then cleans up the ses- 
to the partner LU. sion by sending a SESSEND_SIGNAL to 
| inform SS that the session activation 
2. SM receives a -RSP(BIND) from the partner failed, adjusts (decreases) the number of 
LU. buffers in the permanent buffer pool. SM 


destroys the corresponding HS. 


RM 


ACTIVATE_ . ; 4 
SESSION. . ASSIGN_PCID 
——$—$—$—— >? 0 


a, 
5 . ASSIGN_PCID_RSP | 
: o< iN 
; | y INIT_SIGNAL : a 
1 ‘ >o ‘ 
‘ , é ‘ .(CP cannot proceed 
. successfully with 
‘ oY » session activation. ) 
: . INIT_SIGNAL_NEG_RSP ; 
2 ACTIVATE_ o< re) i 
SESSION _ 
RSP(-) 
3 o< , 
| a 
Figure 4-23. Session Initiation by Local LU: INIT_SIGNAL Is Rejected a 
The following notes correspond to the numbers cessful with the session = activation. 
in Figure 4-23. (See SNA Type 2.1 Node Reference for 
details. ) 
1. SM receives an ACTIVATE_SESSION record 3. SM sends a negative ACTIVATE_SESSION_RSP 
and begins the initiation by sending an to inform RM that the session could not 
INIT_SIGNAL record to SS. be activated. 
2. SM receives an INIT_SIGNAL_NEG_RSP from | os 
SS informing SM that the CP was unsuc- | S | 
BM 
; LFSID_IN_USE . 
| LFSID_IN_USE_RSP . 
> 
Figure 4-24. ASM Checks Whether a Specific (PATH_CONTROL_ID, LFSID) Pair Is in Use by SM 
The following notes correspond to the numbers 2. SM returns an LFSID_IN_USE_RSP to ASM 
in Figure 4-24. with the status of the pair. (See SNA 
Type 2.1 Node Reference for additional aa 
discussion of this exchange. ) C 
1. ASM sends an LFSID_IN_USE record to check oe 


if the specified (PATH_CONTROL_ID, LFSID) 
pair is in use by SM. 
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RM BM 


ACTIVATE_. : : 
SESSION : . ASSIGN_PCID 
o————$—_> 9 7 


' ; . ASSIGN_PCID_RSP | 
* o< 

| .  INIT_SIGNAL : 

Pde) 


DEACTIVATE_. ‘ ; CP proceeds with 

SESSION . 2 : session activation. ) 
QOD . 
é CINIT_SIGNAL 
o< 


| - SESSEND_SIGNAL 
> 


Figure 4-25. Termination of a Pending LU-LU Session before CINIT_SIGNAL Is Received 


The following notes correspond to the numbers 3. SM receives the CINIT_SIGNAL for the ses- 
in Figure 4-25. sion RM has since requested to be deacti- 
vated; thus, the FQPCID does not match 
the FQPCID of any active or 


1. SM receives an ACTIVATE_SESSION record pending-active session. 
and begins the initiation sequence by , 
sending an INIT_SIGNAL to SS. 4. SM sends a SESSEND_SIGNAL to inform SS 
that the session activation was termi- 
a 2. While SM is waiting for the CINIT_SIGNAL nated. 
C from SS in response to the INIT_SIGNAL,; 
RM sends SM a DEACTIVATE_SESSION, which 


caused SM to change the state of the ses- 
sion to RESET. 
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Figure 4-26. 


4-44 


RM 


ACTIVATE_ 
SESSION 
0 ° . ° 
(Initiation proceeds as in Figure 4-10 on page 4-32.) 
BIND 


DEACTIVATE_. 


SESSION 
n> 0 


UNBIND 


| ; SESSEND_SIGNAL . 
>o 


ADJUST_BUFFER_POOL(permanent buffer pool ID) 


+RSP(BIND) or UNBIND 


( ignored ) 


The following notes correspond to the numbers 4. 
in Figure 4-26. 


1. SM receives an ACTIVATE_SESSION record 
and begins the initiation sequence with 
BIND. 5. 


2. While SM is waiting for the RSP(BIND) 
from ASM, RM sends SM a_ DEACTI- 
VATE_SESSION, which causes SM to change 
the state of the session to RESET. 


3. SM sends an UNBIND to ASM to stop the 


session SM is currently in the process of 
activating. 
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Termination of a Session Pending Activation After BIND Is Sent 


SM sends a SESSEND_SIGNAL to inform SS 
that the session activation was unsuc- 
cessful. SM also adjusts (decreases) the 
number of buffers in the permanent buffer 
pool. SM destroys the corresponding HS. 


SM receives the RSP(BIND) from ASM. 
Since SM has already issued an UNBIND for 
the session and has released the FQPCID, 
SM does not have any = active’ or 
pending-active session with an FQPCID 
that matches the FQPCID on the received 
UNBIND; thus it ignores UNBIND. 


a 
~ 
| 
i 
ad oa 


(session traffic) 


- ABORT_HS . , . 
oc 2 


. | : : UNBIND : 
SESSION_ 


DEACTIVATED | , ‘ . 
o< ° 


| , SESSEND_SIGNAL . 
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ADJUST_BUFFER_POOL(permanent buffer pool ID) 


Figure 4-27. SM Receives ABORT_HS While a Session Is Active 


The following notes correspond to the numbers 3. 
in Figure 4-27. 


1. During an active session, HS detects an 
error and sends an ABORT_HS record to SM. 


{ 
i 


SM sends an UNBIND to ASM. At this 
point, SM brings down the session, with- 
out waiting for the RSP(UNBIND). 


+RSP( UNBIND ) 
o< SSS 


(not passed to SM) 


SM sends a SESSION_DEACTIVATED to inform 
RM that the session is being deactivated. 
SM sends a SESSEND_SIGNAL to inform SS 
that the session is being deactivated. 
SM adjusts (decreases) the number of 
buffers in the permanent buffer pool. 
The dynamic and limited buffer pools will 
automatically be destroyed when the HS is 
destroyed; SM destroys the corresponding 
HS. 
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a -(CP proceeds with 
. - session initiation. ) 


: CINIT_SIGNAL : 
ee ©) 
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> 
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. .  ASSIGN_LFSID_RSP ; | 
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ADJUST_BUFFER_POOL( permanent buffer Beer ID) : 


; | : FREE_LFSID : : 
ACTIVATE __ >o 
SESSION __ ; : ; 
RSP(- } 

o< 


SESSEND_SIGNAL. 
> 


Figure 4-28. A Request to Get a Buffer Is Rejected during Session Activation 


The following notes correspond to the numbers 3. SM sends a FREE_LFSID record to ASM. ASM 

in Figure 4-28. normally would get this information from 
the UNBIND, but since a BIND was not 
issued, an UNBIND also is not issued. 

1. RM sends an ACTIVATE_SESSION. The ses- 


sion initiation sequence proceeds as in 4. SM sends a negative ACTIVATE_SESSION_RSP 
Figure 4-10 on page 4-32. to inform RM that the session activation 
failed. we 
2. SM receives a negative response to its 
request to increase the number of buffers 5. SM sends a SESSEND_SIGNAL to inform SS-~---” 
in the permanent buffer pool. At this that the session initiation failed. 


point session initiation cannot continue, 
so SM brings down the session. 
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INTRODUCTION TO FORMAL DESCRIPTION 


ny aaa EES = EEE CET 


The remainder of this chapter contains the 
formal description of SM. This description 
consists of procedural logic, finite-state 
machines (FSMs), and data structures used 
only by SM. The highest level is the root 
procedure of the calling tree, named SM (same 
as the overall component). The SM root pro- 
cedure calls the other procedures. 


The procedures are arranged in the following 
order: first is the highest-level routine SM, 
followed by the routines called by 
SM--PROCESS_RECORD_FROM_RM, PROC- 
ESS _RECORD_FROM_HS,» PROCESS _RECORD_FROM_SS, 
PROCESS _RECORD_FROM_ASM--followed by the 
remaining procedures in alphabetical order. 
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FUNCTION: LU session manager (SM) is responsible for creating the RM process’ and for 
activating and deactivating sessions between this LU and another LU. There is 
one SM process per LU in the node, and it is created and destroyed when the LU 
1s created and destroyed. SM receives records from the resources manager 
(RM), the half-session (HS), the address space manager (ASM), and the session 
services (SS) processes. When the records are received, they are routed to 
the appropriate procedures where they are processed. SM uses process data 
(called LOCAL) that can be accessed by any procedure in the SM process. 


INPUT : At SM creation time: SM_CREATE_PARMS (contains information about the node and 
the LU associated with SM). At run time: records from RM, HS, ASM, or SS. 


OUTPUT : At SM creation time: RM _ process is created and the node operator facility 
(NOF) is informed of that, if successful. Otherwise, the SM _ process ends 
abnormally. A pool of buffers needed by SM is reserved. If buffers are not 
available, SM ends abnormally. 


At run time: received records are routed to appropriate procedures in SM. 
LOCAL.SENSE_CODE is initialized. 


Referenced procedures, FSMs, and data structures: 


RM | page 3-19 
PROCESS RECORD_FROM_RM page 4-49 
PROCESS RECORD_FROM_HS page 4-50 
PROCESS RECORD_FROM_ASM page 4-51 
PROCESS_RECORD_FROM_SS page 4-50 
SM_CREATE_PARMS page A-27 
RM_CREATE_PARMS page A-27 
RM_CREATED page A-27 
LOCAL page 4-89 Pe 
LUCB page A-1l a 
PARTNER_LU page A-2 se 
MODE . page A-3 
LULU_CB page 4-90 
Set up addressability to the control blocks used by SM. The SM 
process data (LOCAL) is a data area that may be referenced by any procedure aaa 
or FSM in SM. LOCAL is referenced only within SM. ( 
The LU control block (LUCB), partner-LU control block (PARTNER_LU in | See 
LUCB.PARTNER_LU_LIST), and mode control block (MODE in PARTNER_LU.MODE_LIST) 
are used but not created by SM. 
The LU-LU control block (LULU_CB in LOCAL.LULU_CB_LIST) is 
created and used only by SM. 
Create RM_CREATE_PARMS record. 
Set RM_CREATE_PARMS.LUCB_LIST_PTR to SM_CREATE_PARMS.LUCB_LIST_PTR. 
Set RM_CREATE_PARMS.LU_ID to SM_CREATE_PARMS.LU_ID. | 
Create RM process while passing RM_CREATE_PARMS to it. 
If RM process is created successfully then 
Create RM_CREATED record. 
Set RM_CREATED.LU_ID to SM_CREATE_PARMS.LU_ID. 
Send RM_CREATED to the NOF component of the node. 
Else (an attempt to create an RM process failed) 
Abend. 
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Call buffer manager(CREATE_BUF_POOL, permanent, buffer size» capacity 
of pool) to obtain a permanent buffer pool. Buffer pool size is set 
to the maximum RU size, capacity of pool is set to 5 (number of 
buffers put in the pool). Permanent buffer pool ID is 
returned by buffer manager. This buffer pool will be shared by all 
HSs created by this SM, and is used for storing normal flow responses, 
IPM acknowledgments, and expedited flows. The number of buffers 
1S increased each time a new HS is created, and decreased each time 
a HS is destroyed (Appendix B). 

If buffers are not available then 

Abend. 


Run-Time Logic 


Do until SM process is destroyed. 
Set LOCAL.SENSE_CODE to X'00000000' to indicate that there is no error 
when an incoming record is received. 
Select based on one of the following conditions: 
When record is received from RM 
Call PROCESS RECORD_FROM_RM(RM_TO_SM_RECORD) (page 4-49). 
When record is received from HS 
Call PROCESS_RECORD_FROM_HS(HS_TO_SM_RECORD) (page 4-50). 
When record is received from ASM 
Call PROCESS_RECORD_FROM_ASM(ASM_TO_SM_RECORD) (page 4-51). 
When record is received from SS 
Call PROCESS_RECORD_FROM_SS(SS_TO_SM_RECORD) (page 4-50). 


PROCESS_RECORD_FROM_RM 


FUNCTION: ‘Route records received from RM to appropriate procedures. 


INPUT: Record from RM: ACTIVATE_SESSION, DEACTIVATE_SESSION, or ABEND_NOTIFICATION 


record 


OUTPUT: Record from RM forwarded to appropriate procedure 


Referenced procedures, FSMs, and data structures: 


PROCESS _ACTIVATE_SESSION page 4-75 
PROCESS DEACTIVATE_SESSION page 4-80 
PROCESS ABEND NOTIFICATION page 4-74 
ACTIVATE_SESSION page A-20 
DEACTIVATE_SESSION page A-21 
ABEND_NOTIFICATION page A-25 


Select based on record from RM: 
When ACTIVATE_SESSION 
Call PROCESS _ACTIVATE_SESSION( ACTIVATE_SESSION ) 
(page 4-75). 
When DEACTIVATE_SESSION 
Call PROCESS_DEACTIVATE_SESSION( DEACTIVATE_SESSION) 


(page 4-80). 
When ABEND_NOTIFICATION (RM process has abended) 
Call PROCESS_ABEND_NOTIFICATION( ABEND_NOTIFICATION) 
(page 4-74). 
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PROCESS _RECORD_FROM_HS | c~ 
Net oy 
FUNCTION: Route records received from the half-session (HS) process to the appropriate 
procedures. 
INPUT: Record from HS: INIT_HS_RSP record, ABORT_HS record, or ABEND_NOTIFICATION 
record 
OUTPUT : Record from HS forwarded to appropriate procedure 
Referenced procedures, FSMs, and data structures: 
PROCESS_INIT_HS_RSP | | page 4-81 
PROCESS _ABORT_HS page 4-74 
PROCESS _ABEND_NOTIFICATION page 4-74 
INIT_HS_RSP page A-10 
ABORT_HS page A-9 
ABEND_NOTIFICATION page A-25 
Select based on record from HS: —_- 
When INIT_HS_RSP S. 
Call PROCESS_INIT_HS_RSP(INIT_HS_RSP) - 
(page 4-81). 
When ABORT_HS 
Call PROCESS _ABORT_HS( ABORT_HS) 
(page 4-74). 
When ABEND_NOTIFICATION (HS process has abended) 
Call PROCESS_ABEND_NOTIFICATION( ABEND_NOTIFICATION ) 
(page 4-74). 
i 
{ 
PROCESS RECORD_FROM_SS . Re ue 
FUNCTION: Route records received from session services (SS) to the appropriate proce- 
dures. 
INPUT : Record from SS: INIT_SIGNAL_NEG_RSP record, or CINIT_SIGNAL record 
OUTPUT : Record from HS forwarded to appropriate procedure 
a eo 
Referenced procedures, FSMs, and data structures: « 
PROCESS_INIT_SIGNAL_NEG_RSP page 4-81 # 
PROCESS CINIT_SIGNAL page 4-79 
INIT_SIGNAL_NEG_RSP page A-23 


CINIT_SIGNAL | page A-23 


Select based on record from SS: 
When INIT_SIGNAL_NEG_RSP 
Call PROCESS INIT_SIGNAL_NEG_RSP( INIT_SIGNAL_NEG_RSP } 
(page 4-81). 
When CINIT_SIGNAL 
Call PROCESS _CINIT_SIGNAL(CINIT_SIGNAL ) 
(page 4-79). 
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PROCESS_RECORD_FROM_ASM 


FUNCTION: Route records received from the address space manager (ASM) to the appropriate 
procedures. 


INPUT: MU, SESSION _ROUTE_INO, or LFSID_IN_USE 


OUTPUT: Record passed to appropriate procedure 


Referenced procedures, FSMs, and data structures: 


PROCESS _MU page 4-82 
PROCESS SESSION_ROUTE_INOP page 4-83 
PROCESS _LFSID_IN_USE page 4-82 
MU page A-29 
SESSION_ROUTE_INOP page A-24 
LFSID_IN_USE page A-26 


Select based on record from ASM: 
a When MU 
F Call PROCESS _MU(MU ) 


When SESSION_ROUTE_INOP 
Call PROCESS _SESSION_ROUTE_INOP(SESSION_ROUTE_INOP } 
(page 4-83). 


(page 4-82). 


When LFSID_IN_USE 
Call PROCESS_LFSID_IN_USE(LFSID_IN_USE } 
(page 4-82). 
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BIND_RQ_STATE_ERROR 


FUNCTION: Determine if there is a state error on receipt of a BIND. 


INPUT: MU record containing BIND 


OUTPUT: TRUE if error detected; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to 


the appropriate sense data value. 


Referenced procedures, FSMs, and data structures: 


BIND_SESSION_ LIMIT_ EXCEEDED page 4-57 
LOCAL page 4-89 
MU page A-29 
PARTNER_LU page A-2 
MODE page A-3 
BIND RU . SNA Formats 
LUCB . page A-1 


Locate the PARTNER_LU control block using the User Data PLU Name field in BIND. 
If PARTNER_LU control block cannot be located then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is offset to PLU Name field). 
Return with a value of TRUE (error). 


Check for FQPCID collisions. The FQPCIDs of two sessions at this LU 
collide if their PCID parts are the same. If such collision is found then 
Set LOCAL.SENSE_CODE to X'083B0001'. 
Return with a value of TRUE (error). 


If the levels of session security between LUs do not match then 
Set LOCAL.SENSE_CODE to X‘'O80F6051' (Security violation). 
Return with a value of TRUE (error). 


Locate the MODE control block using the User Data Mode Name field in BIND. 
If MODE control block cannot be located then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx 1s offset to Mode Name field). 
Return with a value of TRUE (error). 


The following determines the session type for this LU so that the check for 
whether the session limit will be exceeded may be made. 
If parallel sessions are not supported with the partner LU and 
MODE .MIN_CONWINNERS_LIMIT = 1 then 
Set local session_type is FIRST_SPEAKER. 
Else (use value in BIND request) 
If BIND specifies the secondary as esatention winner then 
Set local session_type to FIRST_SPEAKER. 
Else 
Set local session_type to BIDDER. 


Call BIND _SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, 
local session_type) (page 4-57). 
If the session limit will be exceeded then 
Return with a value of TRUE (LOCAL.SENSE_CODE is set by BIND_SESSION_LIMIT_EXCEEDED). 


If partner-LU does not support parallel sessions, and there is another 
session pending with the partner-LU a BIND race condition exists. 
BIND winner is determined by comparing LU names, the LU that sent the 
BIND containing the greater of the two network-qualified LU names is 
the BIND winner. 


If BIND specifies that an alternate code set is to be used and 
the alternate code ID is other than ASCII_* then 
Set LOCAL.SENSE_CODE to X'0835007'. 
Return with a value of TRUE (error). 


Do consistency checks (on PS usage fields for parallel) sessions using either the 
same partner- -LU or the same (partner-LU, mode name) pair (see BIND request in SNA Formats). 
If there is a consistency error then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx 1s offset to inconsistent field). 


Return with a value of TRUE (error). ’ 


ee 


it | i 
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Do consistency checks on conversation-level security indicators 
for parallel sessions using the same PARTNER_LU. 
If there is a consistency error then 
Set LOCAL.SENSE_CODE to X'O80F6051' (Security violation). 
Return with a value of TRUE (error). 


If this LU's cryptography support capability does not match that specified in BIND then 
Set LOCAL.SENSE CODE to X'0835001A'. 
Return with a value of TRUE (error). 


If cryptography is supported with the partner LU, but the cryptography 
component (that enciphers and deciphers) is not active then 
Set LOCAL.SENSE_CODE to X'08480000' (cryptography function inoperative). 
Return with a value of TRUE (error). 


Check the SESSION_ID parameter: 
If a PARTNER_LU indicates that an FQPCID control vector will be used for 
session identification instead of session iristance ID User Data subfield 
(by setting the first byte to X'01' in the User Data SESSION_ID subfield) then 
Use a short (X'02') user data session ID subfield in the RSP(BIND). 
(This procedure checks that in this case the FQPCID control vector is indeed 
present in the BIND. ) 


Else (the first byte of SESSION_ID is not equal to X'01'),; 
Negotiate the SESSION_ID value: 
If the BIND sender's name is greater than the BIND receiver's name then 
Set the first byte of the SESSION_ID to X'FO'. 
Else (the BIND sender's name is not greater than that of the BIND receiver) 
Set the first byte of the SESSION_ID to X'‘'0O'. 


In order to check the uniqueness of SESSION_ID; 
the negotiated SESSION_ID is compared to SESSION_IDs 
for all sessions where the BIND exchange has already occurred. 
If the negotiated SESSION_ID is not unique then 
Set LOCAL.SENSE_CODE to X'08520001'. 
Return with a value of TRUE (error). 


If the PLU does not support receiving of segments and the lower bound 
RU size for the specified mode name > the maximum send BTU size THEN 
Return with a value of TRUE (error). 
Set LOCAL’.SENSE_CODE to '08350006'. 


If this node does not support segment generation and the lower bound 
RU size for the specified mode name > the maximum send BTU size THEN 
Return with a value of TRUE (error). 
Set LOCAL.SENSE_CODE to '0877002A'. 


If this node does not support segment reassembly and the lower bound 

RU size for the specified mode name > the maximum receive BTU size THEN 
Return with a value of TRUE (error). 
Set LOCAL.SENSE_CODE to '0877002B'. 


Return with a value of FALSE (no error). 
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BIND_RSP_STATE_ERROR 


FUNCTION: Perform state error checking on a received +RSP(BIND). 


INPUT: MU containing a +RSP(BIND), LULU_CB control block 


OUTPUT: TRUE if error; otherwise, FALSE. If an error is found, LOCAL.SENSE_CODE is 
set. - | 


Referenced procedures, FSMs, and data structures: 7 

LU_MODE_SESSION_LIMIT_EXCEEDED page 4-72 
MU page A-29 
LULU_CB . page 4-90 
LOCAL page 4-89 
PARTNER_LU | page A-2 
BIND RU | SNA Formats 
MODE page A-3 


If the BIND specified that an alternate code set will not be used and 
the RSP(BIND) specifies that an alternate code set may be used then ( 
Set LOCAL.SENSE_CODE to X'08350006'. \ 
Return with a value of TRUE (error). 


If the RSP(BIND) specifies that an alternate code set may be used and that 
an alternate code process ID is anything but ASCII-8 then | 

Set LOCAL.SENSE_CODE to X‘'08350006'. 

Return with a value of TRUE (error). 


Pacing and maximum RU size checks | | 


If the pacing staging indicators in the RSP(BIND) are not the same as é 
those specified in the BIND then Sut 
Set LOCAL.SENSE_CODE to X'08350008', if secondary to primary staging is not the same, 
or to X'0835000C', if primary to secondary staging is not the same. 
Return with a value of TRUE (error). 


If the RSP(BIND) indicates that adaptive pacing will not be used on this session then 
If the secondary send window size in the RSP(BIND) | 
is not the same as that specified in the BIND then 
Set LOCAL.SENSE_CODE to X‘'08350008'. 
Return with a value of TRUE (error). 


If the secondary receive window size in the RSP(BIND) is greater than that 4 ’ 
specified in the BIND then (a window size of 0 is treated as ( 
infinitely large for these comparisons) 

Set LOCAL.SENSE_CODE to X'08350008'. 
Return with a value of TRUE (error). 


If the primary send window size in the RSP(BIND) is greater than that 
specified in the BIND then (a window size of 0 is treated as 
infinitely large for these comparisons ) 

Set LOCAL.SENSE_CODE to X'0835000C'. 
Return with a value of TRUE (error). 


If the primary receive window size in the RSP(BIND) is not the same as 
that specified in the BIND then 
Set LOCAL.SENSE_CODE to X'0835000D'. 
Return with a value of TRUE (error). 


Determine if the secondary or primary send maximum RU sizes are within installation- 

defined bounds. If path control for the PLU does not support the segment 

reassembly, then secondary send maximum RU size must not exceed the maximum size 

allowed on the Link. 

If the secondary or primary send maximum RU sizes are not within the installation- . ‘ 

defined bounds then C 
Set LOCAL.SENSE_CODE to X'0835000A', if the secondary send RU size is outside 

the bounds, or to X‘'0835000B', if that is true for the primary send RU size. 

Return with a value of TRUE (error). 
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= | PS usage checks 


If there are other active sessions to this partner-LU and 
the levels of conversation security between sessions to this partner-LU 
do not match then 

Set LOCAL.SENSE_CODE to X'O80F6051'. 
Return with a value of TRUE (error). 

If there are other active sessions for this (partner-LU, mode name) pair and 
the values of the RSP(BIND) fields for synchronization level and session 
reinitiation do not equal those of the other active sessions then 

Set LOCAL.SENSE_CODE to X'08350018'. 
Return with a value of TRUE (consistency error). 


Else (no other sessions active for this [partner-LU, mode name] pair) 
If the RSP(BIND) specifies a synchronization level of Confirm, Sync Point, 
and Backout and the BIND specified only Confirm then 
Set LOCAL.SENSE_CODE to X'08350018'. 
22. Return with a value of TRUE (error). 


C. If the RSP(BIND) specifies parallel sessions not supported then 
; If the RSP(BIND) specifies session reinitiation responsibility as not 
operator controlled and the BIND specified operator controlled then 
Set LOCAL.SENSE_CODE to X'‘'08350018'. 
Return with a value of TRUE (error). 


If the RSP(BIND) specifies session reinitiation responsibility as 
secondary will reinitiate and the BIND specified primary will 
reinitiate then 

Set LOCAL.SENSE_CODE to X'08350018'. 
Return with a value of TRUE (error). 


primary will reinitiate and the BIND specified secondary will 
/ reinitiate then 

Set LOCAL.SENSE_CODE to X‘'08350018'. 

Return with a value of TRUE (error). 


(— If the RSP(BIND) specifies session reinitiation responsibility as 
Se 


If the values of the RSP(BIND) fields for parallel sessions support and 

change number of sessions support are not the same as specified in the BIND then 
Set LOCAL.SENSE_ CODE to X'08350018'. 
Return with a value of TRUE (error). 
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Contention winner checks 


If the RSP(BIND) specifies parallel sessions supported then 
If the value of the RSP(BIND) contention winner field is not the 
same as that specified in the BIND then 
Set LOCAL.SENSE_CODE to X‘08035007'. 
Return with a value of TRUE (error). 


Else (parallel sessions not supported) 
If the RSP(BIND) contention winner is specified as the primary and the 
BIND was specified as the secondary then 
Set LOCAL.SENSE_CODE to X‘'08350007'. 
Return with a value of TRUE (error). 


If the RSP(BIND) specifies the primary as the contention winner then 
Set local session_type to FIRST_SPEAKER. 

Else 
Set local session_type to BIDDER. 


Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU. FULLY_QUALIFIED_LU_NAME, 
MODE, local session_type, active) (page 4-72). 
If the session limit will be exceeded then 
Return with a value of TRUE (error). (LOCAL.SENSE_CODE is set by 
LU_MODE_SESSION_LIMIT_EXCEEDED). 


Cryptography checks (required). _ 


If the RSP(BIND) cryptography field values are not the same as those specified 
in the BIND then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is an offset to that cryptography field 
in the RSP(BIND) that is different from the corresponding value in the BIND). 
Return with a value of TRUE (error). | 


User data subfield checks 


If the user-data mode name in the RSP(BIND) is not the same as that 
specified in the BIND then 
Set LOCAL.SENSE_ CODE to X'0835xxxx' (xxxx is an offset to the Mode Name subfield). 
Return with a value of TRUE (error). 
If LU-LU verification is active (LULU_CB.RANDOM is nonempty) then 
If enciphered data is absent or incorrect (see page 4-24) then 
Set LOCAL.SENSE_CODE to X'O80F6051'. 
Return with a value of TRUE (error). 


If the user-data session-instance identifier in the RSP(BIND) is not 
specified correctly or if the negotiated value of the session ID is not unique then 
(see page 4-24 and the SNA Formats). 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is an offset to the session ID subfield). 
Return with a value of TRUE (error). 


URC checks 


If the URC in the RSP(BIND) 1s not the same as that specified 
in the BIND then 
Return with a value of TRUE (error). 


Return with a value of FALSE (no error).. 
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ane BIND_SESSION_LIMIT_EXCEEDED 
C 


FUNCTION: Determine whether or not session limits are exceeded for a received BIND. 


INPUT: PARTNER_LU. FULLY_QUALIFIED_LUNAME, MODE, session_type (FIRST_SPEAKER or BID- 
DER) 


OUTPUT : TRUE if limits exceeded; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set 
to appropriate sense data value. 


Referenced procedures, FSMs, and data structures: 


LU_MODE_SESSION_LIMIT_EXCEEDED page 4-72 
LOCAL page 4-89 
MODE page A-3 
PARTNER_LU page A-2 


If session limit is being negotiated and the proposed 
session limit is > than the current session limit 
: (MODE .CNOS_NEGOTIATION_IN_PROGRESS = TRUE) then 
iy If active session count is 2 the proposed limit then 
Set LOCAL.SENSE_CODE to X‘08050000'. 
Set local return code to TRUE. 


Else 
If the sum of active session count and pending session 
count is >= the proposed session limit then 
Set LOCAL.SENSE_CODE to X'08050000'. 
Set local check_winner_flag to TRUE. 


Else (session limits not being negotiated) 
Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, 


inputted session_type, state_condition( ACTIVE )) (page 4-72). 
C) If the session limit 1s exceeded then 


Set local return code to TRUE (LOCAL.SENSE_CODE set by LU_MODE_SESSION_LIMIT_EXCEEDED) 


Else 
Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_ NAME, 
MODE, inputted session_type,> 
state’ condition(AT_LEAST_BIND_SENT)) (page 4-72}. 
If the session limit is exceeded then 
local check_winner_flag is set to TRUE. 


= Check for BIND race condition 


CC If local check_winner_flag is true then 
Determine which LU is the BIND race winner. A comparison is made between the 
SLU name and PLU name (PARTNER_LU.FULLY_QUALIFIED_LU_NAME ) 
using the EBCDIC collating sequence. 
The "greater" one is the winner. Before the comparison is made, the shorter 
name is padded with space (X'40') characters so that the lengths are equal. 


If this LU is the winner then 
Set local return code to TRUE. 


Else 
Reset LOCAL.SENSE_CODE to X'00000000'. 
Set local return code to FALSE. 
Return with the value of local return code. 
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BUILD_AND_SEND_ACT_SESS_RSP_NEG cr 


FUNCTION: Build and send ACTIVATE_SESSION_RSP (negative) to RM. 


INPUT: Correlator (in LULU_CB or ACTIVATE_SESSION) to activate-session request and 
error type (retry or no retry) | 


OUTPUT: ACTIVATE_SESSION_RSP to RM 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
_ ACTIVATE_SESSION_RSP page A-13 
ACTIVATE_SESSION page A-20 
LULU_CB | page 4-90 


Create an ACTIVATE_SESSION_RSP record. 

Set ACTIVATE_SESSION_RSP.CORRELATOR to passed correlator. 

Set ACTIVATE_SESSION_RSP.TYPE to NEG. pee 
Set ACTIVATE_SESSION_RSP.ERROR_TYPE to passed error type. ( 


Send an ACTIVATE_SESSION_RSP record to RM. nee 


BUILD_AND_SEND_ACT_SESS_RSP_POS 


FUNCTION: Build and send ACTIVATE_SESSION_RSP (positive) to RM. This completes (from 
the SSM's standpoint) the session initiation activity triggered by the ACTI- 
VATE_SESSION record received by SM from RM. 


INPUT: LULU_CB control block 


OUTPUT: ACTIVATE_SESSION_RSP created and sent to RM 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
LULU_CB page 4-90 
ACTIVATE_SESSION_RSP page A-13 
Create an ACTIVATE_SESSION_RSP record. a, 
Set ACTIVATE_SESSION_RSP.CORRELATOR to LULU_CB.CORRELATOR. \ 


Set ACTIVATE_SESSION_RSP.TYPE to POS (positive response). ee 


Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.HS_ID to LULU_CB.HS_ID. 
Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.HALF_SESSION_TYPE to PRI. 
Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.BRACKET_TYPE to LULU_CB.SESSION_TYPE. 


Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.SEND_RU_SIZE to 
the negotiated maximum send RU size. 

Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION. PERMANENT_BUFFER_POOL_ID to 
the ID of the permanent buffer pool. 

Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.LIMITED_BUFFER_POOL_ID to 
the ID of the limited buffer pool. 


Set ACTIVATE_SESSION_RSP .SESSION_INFORMATION.SESSION_IDENTIFIER to 
LULU_CB.SESSION_ID. 


Send random data to RM. This is used to build the FMH-12. 


™ 
Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.RANDOM_DATA to LULU_CB.RANDOM. Cc 
Send ACTIVATE_SESSION_RSP TO RM. 
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\ 
eA 
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BUILD_AND_SEND_BIND_RQ 


FUNCTION: Build and send a BIND 


INPUT : 


LULU_CB control block 


OUTPUT: A BIND request to ASM 


Referenced procedures, FSMs, and data structures: 


LUCB 
LULU_CB 
MU 

BIND RU 
ASM 


Call buffer manager(GET_BUFFER, demand, buffer size, no wait) 
to get a demand buffer to contain the BIND. Buffer size is the 


length of BIND including control vectors plus length of MU overhead. 


(Appendix B). 


Set 
Set 
Set 
Set 
Set 
Set 
Set 
Set 
Set 

to 
Set 


MU. 
.BIND_RQ_SEND.LU_ID to this LU's identifier. 
.BIND_RQ_SEND.SENDER.TYPE to SM. 

.-BIND_RQ_SEND.LFSID to LULU_CB.LFSID. 
-BIND_RQ_SEND.TRANSMISSION_PRIORITY to NETWORK. 
.BIND_RQ_SEND.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 
.BIND_RQ_SEND.HS_ID to this half-session's identifier. 


an 


HEADER_TYPE to BIND_RQ SEND. 


MU.TH.SNF field to a unique value. 


the remaining TH and RH fields in MU 

the specified values (see page 4-14 and SNA Formats). 

BIND RU to the appropriate values (see page 4-19). 

Insert the random data into the LUCB.PENDING_RANDOM_DATA_LIST. 
Set MU.DCF to (RH + RU) length. 


Send a BIND MU to ASM. 


BUILD_AND_SEND_BIND_RQ 


page A-1l 

page 4-90 

page A-29 

SNA Formats 

T2.1 Node Reference 


Chapter 4. LU Session Manager 4-59 


BUILD_AND_SEND_BIND_RSP_NEG 


BUILD_AND_SEND_BIND_RSP_NEG 


FUNCTION: Build. and send a -RSP(BIND). 


INPUT: Buffer where a -RSP(BIND) will be stored 


OUTPUT: -RSP(BIND) MU to ASM 


Referenced procedures, FSMs, and data structures: 


MU page A-29 
BIND_RSP_SEND, see MU page A-29 
LOCAL page 4-89 
ASM T2.1 Node Reference 


Set MU.HEADER_TYPE to BIND_RSP_SEND. 


Set MU.BIND_RSP_SEND.SENDER.ID to this LU's identifier. 

Set MU.BIND_RSP_SEND.SENDER.TYPE to SM. 

Set MU.BIND_RSP_SEND.LFSID to the LFSID received in the BIND MU. 

Set MU.BIND_RSP_SEND.PATH_CONTROL_ID to the PATH_CONTROL_ID | : C- 
received in the BIND MU, 000 a 

Set MU.BIND_RSP_SEND.TRANSMISSION_PRIORITY to LOW. 

Set MU.BIND_RSP_SEND.FREE_LFSID to YES. 

Set MU.BIND_RSP_SEND.HS_ID to NULL. 


Set TH and RH fields in the RSP(BIND) MU to appropriate values 
(see page 4-14 and SNA Formats). 

Set the RU portion of the RSP(BIND) MU to LOCAL.SENSE_CODE followed by 
BIND request code. 

Set MU.DCF to (RH + RU) length. 


Send -RSP( BIND) MU to ASM. 


BUILD_AND_SEND_FREE_LFSID 


FUNCTION: Build and send a FREE_LFSID record to the control point. This is necessary 
when SM asked ASM to give SM an LFSID for a_ session, and SM_ received 
ASSIGN_LFSID_RSP, but could not send a BIND (because, for example, SM cannot 
get a buffer for it). In this case, SM explicitly asks ASM to free the LFSID 
by sending the FREE_LFSID record to it. If SM sends a BIND successfully, it 
later sends an UNBIND or a RSP(UNBIND) to ASM and sets the FREE_LFSID variable 
to YES in them. | 


INPUT: LULU_CB control block 


OUTPUT: FREE_LFSID record to the ASM component of the control point 


Referenced procedures, FSMs, and data structures: 


LULU_CB page 4-90 
FREE_LFSID page A-25 
ASM T2.1 Node Reference 


Create a FREE_LFSID record. 


Set FREE_LFSID.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 
Set FREE_LFSID.LFSID to LULU_CB.LFSID. 


Send FREE_LFSID record to ASM. 
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BUILD_AND_SEND_INIT_HS 


BUILD_AND_SEND_INIT_HS 


FUNCTION: Build an INIT_HS (initialize half-session) record and send it to the 
half-session designated by the passed LULU_CB. 


INPUT: LULU_CB, first 26 bytes of the negotiated BIND image 


OUTPUT: INIT_HS record to HS (LU-LU half-session) 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
LULU_CB page 4-90 
INIT_HS page A-13 
LOCAL page 4-89 


Create INIT_HS record. 
Set the following fields in the INIT_HS record: PATH_CONTROL_ID, LFSID, 
HALF_SESSION_TYPE, DYNAMIC_POOL_ID, DEM_LIM_POOL_ID, and 
a TRANSMISSION_PRIORITY by copying the corresponding fields 
C from the LULU_CB control block. 
Set INIT_HS.SHORT_BIND_IMAGE to the passed 26 bytes of the BIND image. 


If adaptive pacing was negotiated for the session then 
Reset all the window size parameters in INIT_HS.SHORT_BIND_IMAGE 
(SEC_SEND_WINDOW_SIZE, PRI_SEND_WINDOW_SIZE, SEC_RCV_WINDOW_SIZE, and 
PRI_RCV_WINDOW_SIZE) to l. 


Send INIT_HS record to HS (the LU-LU half-session identified by LULU_CB.HS_ID). 
If send fails (because the HS has ABEND) then 
Destroy INIT_HS record. 
Set LOCAL.SENSE_CODE to X'0812000D' (use the same sense code as if 
there were insufficient buffers to activate a session). 


BUILD_AND_SEND ‘INIT_SIG 


FUNCTION: Build and send an INIT_SIGNAL record to the control point. 


(~ INPUT: LULU_CB control block 
ene 


OUTPUT : INIT_SIGNAL record to the SS component of the control point 


Referenced procedures, FSMs, and data structures: 


LULU_CB page 4-90 

LUCB page A-1 
INIT_SIGNAL page A-23 

ss T2.1 Node Reference 


Create an INIT_SIGNAL record. 


Set INIT_SIGNAL.SM_PROCESS_ID to this LU's identifier. 
Set INIT_SIGNAL.FQPCID to LULU_CB.FQPCID. 

Set INIT_SIGNAL.SLU_NAME to LULU_CB.FQ_PARTNER_LU_NAME. 
Set INIT_SIGNAL.PLU_NAME to LUCB.FULLY_QUALIFIED_LU_NAME. 
Set INIT_SIGNAL.MODE_NAME to LULU_CB.MODENAME . 


Send an INIT_SIGNAL record to SS. 
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BUILD_AND_SEND_PC_HS_DISCONNECT 
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BUILD_AND_SEND_PC_HS_DISCONNECT 


Build and send a PC_HS_ DISCONNECT record to ASM. This is done only after a 
PLU receives a -RSP(BIND). If, instead, SM receives an UNBIND, it sends a 
RSP(UNBIND), asking ASM to free LFSID, thus disconnecting PC and HS. 


LULU_CB control block 


PC_HS_DISCONNECT record to ASM 


Referenced procedures, FSMs, and data structures: 


PC_HS_DISCONNECT page A-24 
LULU_CB ‘page 4-90 
ASM T2.1 Node Reference 


Create a PC_HS_DISCONNECT record. 


Set PC_HS_DISCONNECT.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 


Set PC_HS_DISCONNECT.LFSID to LULU_CB.LFSID. | ers 

Send a PC_HS_DISCONNECT record to ASM. - 
a 
eet 
—_ 
| 
Nee 
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BUILD_AND_SEND_SESS_ACTIVATED 


BUILD_AND_SEND_SESS_ACTIVATED 


Build and send SESSION_ACTIVATED to RM to indicate that anew session has 
become active and to give RM the information about this session. 


LULU_CB control block 


SESSION_ACTIVATED to RM 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
LULU_CB page 4-90 
SESSION_ACTIVATED page A-14¢ 


Create a SESSION_ACTIVATED record. 


Set 
Set 
Set 
Set 
Set 


Set 


Set 


Set 


Set 
Set 


SESSION_ACTIVATED.SESSION_INFORMATION.HS_ID to LULU_CB.HS_ID. 
SESSION_ACTIVATED .SESSION_INFORMATION.HALF_SESSION_TYPE to SEC. 
SESSION_ACTIVATED .SESSION_INFORMATION.BRACKET_TYPE to LULU_CB.SESSION_TYPE. 


SESSION_ACTIVATED.SESSION_INFORMATION.SEND_RU_SIZE to the 
negotiated maximum send RU size. 

SESSION_ACTIVATED.SESSION_INFORMATION. PERMANENT_BUFFER_POOL_ID to 
LULU_CB.PERM_POOL_ID. 

SESSION_ACTIVATED.SESSION_INFORMATION.LIMITED_BUFFER_POOL_ID to 
LULU_CB.DEM_LIM_POOL_ID (ID of limited buffer pool). 


SESSION_ACTIVATED.SESSION_INFORMATION.SESSION_IDENTIFIER to 
LULU_CB.SESSION_ID. 


Send random data to RM to verify the FMH-12's enciphered data received 
by RM. 


SESSION_ACTIVATED .SESSION_INFORMATION.RANDOM_DATA 
to LULU_CB.RANDOM. 


SESSION_ACTIVATED.LU_NAME to LULU_CB.LOCAL_PARTNER_LU_NAME. 
SESSION_ACTIVATED.MODE_NAME to LULU_CB.MODENAME. 


Send a SESSION_ACTIVATED record to RM. 
If send fails (RM has abended) then 


Destroy SESSION_ACTIVATED record. 
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BUILD_AND_SEND_SESS_DEACTIVATED 
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BUILD_AND_SEND_SESS_DEACTIVATED 


FUNCTION: Build and send SESSION_DEACTIVATED to RM to indicate that an active session 


has been deactivated. 


INPUT: HS_ID (process identifier of half-session deactivated), 
deactivation), SENSE_CODE 


OUTPUT: SESSION_DEACTIVATED record to RM 


Referenced procedures, FSMs, and data structures: 
RM 
SESSION_DEACTIVATED 


Create a SESSION_DEACTIVATED record. 


REASON (reason for 


page 3-19 
page A-14¢ 


Set SESSION_DEACTIVATED.HS_ID to the value of HS_ID passed to this routine. 
Set SESSION_DEACTIVATED.REASON to the value of REASON passed to this routine. 


If REASON is not NORMAL then 


Set SESSION_DEACTIVATED.SENSE_CODE to value of SENSE_CODE passed to this routine. 


Send a SESSION_DEACTIVATED record to RM. 
If send fails (RM has abended) then 
Destroy SESSION_DEACTIVATED record. 


BUILD_AND_SEND_SESSEND_SIG 


FUNCTION: Build and send a SESSEND_SIGNAL record to the control point. This record can 
be sent by both PLU and SLU when the session is brought down. The PLU sends 
it, however, only if it has previously received a CINIT_SIGNAL record. The 
SLU sends it only if it has already sent a SESSST_SIGNAL record to SS. 


INPUT: LULU_CB, LOCAL .SENSE_CODE 


OUTPUT: SESSEND_SIGNAL record to the SS component of the control point 


Referenced procedures, FSMs, and data structures: 
LULU_CB : 
LOCAL 
SESSEND_SIGNAL 
SS 


Create a SESSEND_SIGNAL record. 

Set SESSEND_SIGNAL.SENSE_CODE to LOCAL.SENSE_CODE. 

Set SESSEND_SIGNAL.FQPCID to LULU_CB.FQPCID. 

Set SESSEND_SIGNAL.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 


Send a SESSEND_SIGNAL record to SS. There is no need to check to see 


if the send failed because if the send did fail SS has abended> and 
the whole node will be down. 
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page 4-89 
page A-24¢ 
T2.1 Node Reference 


BUILD_AND_SEND_SESSST_SIG 


BUILD_AND_SEND_SESSST_SIG 


FUNCTION: Build and send a SESSST_SIGNAL record to the control point. 


This record is 


sent by the SLU when it receives the INIT_HS_RSP record from the half-session 
process, The PLU does not need to send it, since its local SS sends a 
CINIT_SIGNAL to SM and assumes that the session will be activated. 


INPUT: LULU_CB 


OUTPUT: SESSST_SIGNAL record to the SS component of the control point 


Referenced procedures, FSMs, and data structures: 
LULU_CB 
SESSST_SIGNAL 
SS 


Create a SESSST_SIGNAL record. 
Set SESSST_SIGNAL.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 
Send a SESSST_SIGNAL record to SS. 


BUILD_AND_SEND_UNBIND_RQ 


FUNCTION: Build and send an UNBIND. 


INPUT: Buffer where UNBIND will be stored, CLEANUP type, sense code 


OUTPUT : UNBIND MU to ASM 


page 4-90 
page A-24 
T2.1 Node 


Reference 


Referenced procedures, FSMs, and data structures: 
MU 
UNBIND_RQ_ SEND, see MU 
LOCAL 
LULU_CB 
ASM 


Set MU.HEADER_TYPE to UNBIND_RQ SEND. 


Set MU.UNBIND_RQ SEND.SENDER.ID to LOCAL.LU_ID. 

Set MU.UNBIND_RQ_SEND.SENDER.TYPE to SM. 

Set MU.UNBIND_RQ SEND.LFSID to LULU_CB.LFSID. 

Set MU.UNBIND_RQ_SEND.PATH_CONTROL_ID to the 
LULU_CB.PATH_CONTROL_ID. 

Set MU.UNBIND_RQ_SEND.TRANSMISSION_PRIORITY to 
LULU_CB.TRANSMISSION_PRIORITY. 

Set MU.UNBIND_RQ_SEND.FREE_LFSID to YES. 

Set MU.UNBIND_RQ_SEND.HS_ID to LULU_CB.HS_ID. 


Set TH and RH fields in the UNBIND MU to appropriate values 
(see page 4-14 and SNA Formats). 

Set the RU portion of the UNBIND MU to appropriate values 
(see page 4-27 and SNA Formats). Use the inputted type and 
sense code values to set corresponding fields in the UNBIND RU. 

Set MU.DCF to (RH + RU) length. 


Send UNBIND MU to ASM. 


page A-29 
page A-29 
page 4-89 
page 4-90 
T2.1 Node 


Reference 
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BUILD_AND_SEND_UNBIND_RSP 


FUNCTION: Build and send a RSP(UNBIND). 


INPUT: MU record containing UNBIND 


OUTPUT : A RSP(UNBIND) MU to ASM 


Referenced procedures, FSMs, and data structures: 


LULU_CB | page 4-90 
MU page A-29 
MU_NEW, see MU page A-29 
ASM T2.1 Node Reference 


If either UNBIND arrived as an EXR or a length error was detected locally then 
A -RSP(UNBIND) will be built. . | 
Else 
A +RSP(UNBIND) will be built. 


Call buffer manager(GET_BUFFER, demand, buffer size, no wait) a 
to get a demand buffer to build RSP(UNBIND) (+ or -) in. Set buffer \ 
size to the length of RSP(BIND) plus length of MU overhead. 

(Appendix B). 


If buffer was gotten successfully then 
Set MU_NEW.HEADER_TYPE to UNBIND_RSP_SEND. 
Set MU_NEW.UNBIND_RSP_SEND.LU_ID to this LU's identifier. 
Set MU_NEW.UNBIND_RSP_SEND.SENDER.TYPE to SM. 


If UNBIND was correlated to a particular session then 
Set MU_NEW.UNBIND_RSP_SEND.HS_ID to LULU_CB.HS_ID. 
Set MU_NEW.UNBIND_RSP_SEND.TRANSMISSION PRIORITY to 

LULU_CB.TRANSMISSION_PRIORITY (LOW, MEDIUM, or HIGH only). 

Else . - 

Set MU_NEW.UNBIND_RSP_SEND.HS_ID to NULL. Na oo 

Set MU_NEW.UNBIND_RSP_SEND.TRANSMISSION_ PRIORITY to LOW. 


Set MU_NEW.UNBIND_RSP_SEND.FREE_LFSID to YES. 
Copy the PATH_CONTROL_ID, LFSID and TH.SNF fields from MU into MU_NEN. 
Set the remaining TH and RH fields in MU_NEW 

to the specified values (see page 4-14¢ and SNA Formats). 


If an RSP(UNBIND) is positive then 
Set the only byte present in the RSP(UNBIND) RU 
to the UNBIND request code. ; 
Else (RSP(UNBIND) is negative) (a. 
Set the RU portion of the RSP(UNBIND) MU to the sense data (that describes \ 
an UNBIND error) followed by the UNBIND request code. ee” 


Set MU.DCF to (RH + RU) length. 
Send RSP(UNBIND) MU to ASM. 


Else (Buffer was not obtained) 
Do nothing, RSP(UNBIND) will not be sent. 
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BUILD_BIND_RSP_POS 


BUILD_BIND_RSP_POS 


FUNCTION: Build +RSP(BIND). 


INPUT: MU record containing the received BIND, LULU_CB control block 


OUTPUT: MU_NEW record containing a +RSP(BIND) 


Referenced procedures, FSMs, and data structures: 


MU page A-29 
MU_NEW, see MU page A-29 
LOCAL page 4-89 
LULU_CB page 4-90 


Call buffer manager(GET_BUFFER, demand, buffer size, no wait) 
to get a demand buffer to build the +RSP(BIND) in. The buffer size is 
set to the length of the RSP(BIND) including control vectors plus length 
of MU overhead (Appendix B). 


If buffer request failed then 
Set LOCAL.SENSE_CODE to X'0812000D' to indicate insufficient buffers 
to activate a session. 
Else 
Set MU_NEW.HEADER_TYPE to BIND _RSP_SEND. 
Set MU_NEW.BIND_RSP_SEND.LU_ID to LOCAL.LU_ID. 
Set MU_NEW.BIND_RSP_SEND.SENDER.TYPE to SM. 
Set MU_NEW.BIND_RSP_SEND.TRANSMISSION PRIORITY to NETWORK. 
Set MU_NEW.BIND_RSP_SEND.FREE_LFSID to NO. 
Set MU_NEW.BIND_RSP_SEND.HS ID to LULU_CB.HS ID. 
Copy the PATH_CONTROL_ID, LFSID and TH.SNF fields from MU into MU_NENW. 
Set the remaining TH and RH fields in MU_NEW 
to the specified values (see page 4-14 and SNA Formats). 
Set RSP(BIND) RU to the appropriate values (see page 4-24). 
Insert the random data found in the received BIND RU 
into the LUCB.PENDING RANDOM DATA_LIST. 
Set MU.DCF to (RH + RU) length. 


CLEANUP_LU_LU_SESSION 


FUNCTION: Clean up LU-LU session. 


INPUT: LULU_CB of session to be cleaned up 


OUTPUT: LU-LU session cleaned up: SESSEND_SIGNAL sent to SS, if appropriate; the 
buffers reserved for this session by SM released; the half-session process for 
this session destroyed, if it exists; an outstanding random data entry removed 
from the pending random data list, if it is there 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_SESSEND_SIG page 4-64 
UNRESERVE_BUFFERS page 4-85 
LULU_CB | page 4-90 


If a SESSST_SIGNAL was previously sent or a CINIT_SIGNAL was received 
on this session then 
Call BUILD_AND_SEND_SESSEND SIG(LULU_CB) (page 4-64). 


Call UNRESERVE_BUFFERS(LULU_CB) to unreserve the buffers reserved for 
this session (page 4-85). 
Destroy this session's half-session process if it exists. 


Remove an entry from the list of pending random data, if the random data 
for this session is there. 
Remove the LULU_CB from the list so the LU-LU awareness is gone. 


Chapter 4. LU Session Manager 4-67 


CORRELATE_BIND_RSP 


4-68 


CORRELATE_BIND_RSP 


FUNCTION: 


INPUT: 


OUTPUT : 


Referenced procedures, FSMs, and data structures: 


MU 


A 


Check if the received RSP(BIND) correlates with a previously sent BIND. 


MU containing the RSP(BIND) 


TRUE, if RSP(BIND) correlates; FALSE, otherwise 


correlation of a RSP(BIND) to BIND is a complicated procedure, par- 


tially because a number of race conditions may occur. The 
PATH_CONTROL_ID and LFSID fields in the RSP(BIND) MU must match those 
in the sent BIND MU and the session in question must be in the state 
where a response to BIND is expected, but this is not enough. Only if 
no -RSP(BIND)s are sent and every +RSP(BIND) carries an FQPCID control 
vector can each RSP(BIND) be properly correlated to a previously sent 
BIND. In doing the correlation, the following problems occur: 


A partner LU may include the FQPCID control vectors in the 
+RSP(BIND)/and use an UNBIND to reject a BIND; or if itis a 
back-level LU, not use FQPCID and send -RSP(BIND) to reject a 
BIND. A back-level LU returns an SNF that is used for corre- 
lation; a current-level LU does not have to return the matched 
SNF. 


A length error may be found while checking whether or not the 
RSP(BIND) contains the FQPCID control vector. Since the presence 
of an FQPCID is in question, an SNF parameter cannot be used for 
correlation, because the RSP(BIND) could arrive from an LU that 
didn't use it. 


Unlike BIND pacing, RSP(BIND) pacing is not required; it 1s possi- 
ble that the ASM could not reassemble the RSP(BIND) that arrived 
from another node. In this case, ASM sends only the first segment 
of the RSP(BIND) MU to the session manager. SM _ recognizes it by 


checking the End of BIU Indicator in the TH. In this case, SM 
also does not Know whether an FQPCID control vector was present in 
the RSP(BIND). 


In view of the above, the following rules are used to check for the 
RSP(BIND) correlation: 


i. 


PATH_CONTROL_ID and LFSID in the received RSP(BIND) must match the 
PATH_CONTROL and LFSID values for a pending-active session and the 
activation process of that session must be in a state where a 
RSP(BIND) is expected. If such a pending-active session is not 
found, no other consideration is given to this RSP(BIND). 


The SNF fields in the BIND and -RSP(BIND) must match. 


If it is Known that +RSP(BIND) lacks an FQPCID control vector, the 
SNF fields in the BIND and RSP(BIND) must match. 


If it is Known that +RSP(BIND) carries an FQPCID control vector, 
the FQPCID must match the one in the BIND. The SNF fields are not 
compared. 


If it cannot be determined whether the FQPCID control vector is 
present in +RSP(BIND), a RSP(BIND) is accepted as correlated under 
the first rule above. The SNF fields are not compared. 
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CORRELATE_UNBIND_RQ 


FUNCTION: 


INPUT: 


OUTPUT: 


Check if the received RSP(UNBIND) correlates with a Known session. 


MU containing the UNBIND 


TRUE, if UNBIND correlates; otherwise, FALSE 


Referenced procedures, FSMs, and data structures: 


MU 


A correlation of an UNBIND to a_ Known session is a complicated proce- 
dure, although not as complicated as a correlation of a RSP(BIND) to a 
BIND. The PATH_CONTROL_ID and LFSID fields in the UNBIND MU header 
must match those used to activate the session in question, but this is 
not enough to complete the correlation. Only if every UNBIND carries 
an FQPCID control vector can each UNBIND be properly correlated to the 
right session. In doing the correlation, the following problems 
occur: 


e A partner LU may include the FQPCID control vector in the UNBIND 
or, if it is a back-level LU, not use FQPCID control vectors. 


A length error’ can be found while trying to find out whether or 
not the RSP(UNBIND) contains the FQPCID control vector. 


The local LU may already have sent an UNBIND of its own and the 
(LFSID, PATH_CONTROL_ID) pair is in use for another session. 


In view of the above, the following rules are used to check for the 
UNBIND correlation: | 


PATH_CONTROL_ID and LFSID in the received UNBIND must match the 
PATH_CONTROL_ID and LFSID for a_ pending-active or active session. 
If such a session is not found, the UNBIND does not correlate. 


If the UNBIND arrives as an EXR’ (RH.SDI=SD), or if it contains 
length errors, or if it is Known that the UNBIND lacks an FQPCID 
control vector, then UNBIND is accepted as correlated under the 
first rule above. 


If it is Known that the UNBIND carries an FQPCID control vector, 
the FQPCID must match the FQPCID of the session. 
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GET_F@PCID 


FUNCTION: Get the fully-qualified procedure correlation identifier (FQPCID) from the 
session services (SS) component of the control point. Repeat requests if a 
duplicate FQ PCID was received. An FQ PCID is considered duplicate if its 
PCID matches that for another active or pending-active session at this LU. 


INPUT: LULU_CB 


OUTPUT: ASSIGN_PCID to SS, LULU_CB.FQPCID initialized 


Referenced procedures» FSMs, and data structures: 


LULU_CB page 4-90 
ASSIGN_PCID page A-22 
ASSIGN_PCID_RSP page A-23 
ss T2.1 Node Reference 


Do until a valid PCID is found. 
Create an ASSIGN_PCID record. 
Set ASSIGN_PCID.SM_PROCESS_ ID to this LU_ID. 
Set ASSIGN_PCID.DUPLICATE_PCID to NO. 


Send ASSIGN_PCID to SS. 

Receive ASSIGN_PCID_RSP from SS. 

Find an LULU_CB with the FQPCID whose PCID field matches that of an FQPCID 

for another session at this LU. 

If found then 
Create another ASSIGN_PCID record. Set all parameters in it to the same 
values as before except that ASSIGN_PCID.DUPLICATE_PCID is set to YES. 
Send a new ASSIGN_PCID record -to SS. 
Receive ASSIGN_PCID_RSP from SS. 


When an acceptable FQPCID is received, save 1%t in LULU_CB.FQPCID. 
Destroy ASSIGN_PCID record. 


INITIALIZE_LULU_CB_ACT_SESS 


FUNCTION: Initialize an LULU_CB for an LU-LU session being activated as a result of an 
ACTIVATE_SESSION received from RM. 


INPUT: ACTIVATE_SESSION record, LULU_CB 


OUTPUT: The following parameters in LULU_CB are initialized: LOCAL_PARTNER_LU_NAME, 
FQ_PARTNER_LU_NAME, MODENAME, and SESSION_TYPE 


Se 
ee 


Referenced procedures, FSMs» and data structures: 


ACTIVATE_SESSION page A-20 
LULU_CB page 4-90 
PARTNER_LU page A-2 


Locate the PARTNER_LU control block using ACTIVATE_SESSION.LU_NAME. 


Set LULU_CB.FQ_PARTNER_LU_NAME to PARTNER_LU.FULLY_QUALIFIED_LU_NAME. 
Set LULU_CB.LOCAL_PARTNER_LU_NAME to PARTNER_LU.LOCAL_LU_NAME. 

Set LULU_CB.MODENAME to ACTIVATE_SESSION.MODE_NAME . 

Set LULU_CB.SESSION_TYPE to ACTIVATE_SESSION.SESSION_TYPE. 
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INITIALIZE_LULU_CB_BIND 


FUNCTION: Initialize an LULU_CB for an LU-LU session being activated as a_ result of 
receiving a BIND. 


INPUT: MU (containing BIND), LULU_CB 


OUTPUT: LULU _CB (initialized) 


Referenced procedures, FSMs, and data structures: 


GET_FQPCID page 4-70 
MU page A-29 
PARTNER_LU page A-2 
LULU_CB page 4-90 
LOCAL page 4-89 
BIND RU SNA Formats 


Locate the PARTNER_LU control block using the user data PLU name in BIND. 
Be Set LULU_CB.LOCAL_PARTNER_LU_NAME to PARTNER_LU.LOCAL_LU_NAME. 
. Set LULU_CB.FQ_PARTNER_LU_NAME to LOCAL.USER_DATA.PLUNAME .NAME . 
22 Set LULU_CB.MODENAME to user data mode name in BIND. 
Set LULU_CB.HALF_SESSION_TYPE = SEC (BIND receiver is secondary). 


If parallel sessions are not supported with the partner LU and 
MODE .MIN_CONWINNERS_LIMIT = 1 then 
Set LULU_CB.SESSION_TYPE to FIRST_SPEAKER. 


Else (negotiation is not allowed in this case) 
If BIND specifies secondary as contention winner then 
Set LULU_CB.SESSION TYPE to FIRST_SPEAKER. 
Else 
Set LULU_CB.SESSION TYPE to BIDDER. 


¢é Set LULU_CB.PATH_CONTROL_ID to the PATH_CONTROL_ID from the BIND. 
/ Set LULU_CB.PC_CHARACTERISTICS to MU.BIND_RU.PC_CHARACTERISTICS. 
Set LULU_CB.LFSID to MU.BIND_RU.LFSID. 


If the FQPCID control vector is present in the BIND then 
Save it in LULU_CB.FQPCID. 

Else 
Call GET_FQPCID(LULU_CB) to get FQPCID. (page 4-70). 
Save FQPCID in LULU_CB.FQPCID. 
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LU_MODE_SESSION_LIMIT_EXCEEDED 


FUNCTION: Determine whether or not session limits associated with a given (LU, mode 
name) pair are exceeded for the given state condition (FSM_STATUS for this 
session). 


INPUT: PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, session type (FIRST_SPEAKER or BID- 
DER), state_condition (ACTIVE, AT_LEAST_BIND_SENT, or AT_LEAST_INIT_SENT) 


OUTPUT : TRUE if session limits exceeded; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE 


is set to appropriate sense data. 


NOTE: If parallel sessions are not supported with the partner LU and the total ses- 
sion limit will not be exceeded, a session-activation request specifying this 
LU as first speaker is accepted. For example, a BIND is received specifying 
the SLU as first speaker (contention winner). The SLU does not support paral- 
lel sessions with the BIND sender and SESSION_LIMIT=1, MIN_CONWINNERS_LIMIT=0, 
and MIN_CONLOSERS_LIMIT=1 (these values are associated with the mode name 
specified in the BIND). Even though the MIN_CONWINNERS LIMIT of 0 will be 
exceeded, the BIND is accepted. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 4-89 
MODE page A-3 


If state_condition = ACTIVE then 
Set BIDDER_SESSION COUNT to the number of active bidder sessions. 
Set FSP_SESSION_COUNT to the number of active first-speaker sessions. 
(A session is considered active if either a RSP(BIND) was received 
if PLU; or a BIND was received, if SLU). 


Else 
If state_condition = AT_LEAST_BIND_SENT then 
Set BIDDER_SESSION_COUNT and FSP_SESSION_COUNT a 
to the number of bidder and first-speaker sessions, respectively, ( 
for which a BIND is either sent or received. Se 


Else (state_condition = AT_LEAST_INIT_SENT) 
Set BIDDER_SESSION COUNT and FSP_SESSION_COUNT 
to the number of bidder and first-speaker sessions, respectively, 
for which either an INIT_SIGNAL is sent, if PLU, or a BIND 
is received, if SLU. 


Set TOTAL_LIMIT to MODE.SESSION_LIMIT. 
Set FSP_LIMIT to MODE.MIN_CONWINNERS_ LIMIT. 
Set BIDDER_LIMIT to MODE .MIN_CONLOSERS_ LIMIT. 


sae 
Select based on one of the following conditions: C 
When FSP_SESSION_COUNT + BIDDER_SESSION_COUNT 2 TOTAL_LIMIT aa 
Set LOCAL.SENSE_CODE to X'08050000' (total session limit will be exceeded). 
When FSP_SESSION_COUNT 2 TOTAL_LIMIT - BIDDER_LIMIT and 
session_type = FIRST_SPEAKER and parallel sessions are supported with 
the partner LU (see Note). 
Set LOCAL.SENSE_CODE to X'08050001' (first speaker session limit will be 
exceeded ). 
When BIDDER_SESSION_COUNT - TOTAL_LIMIT - FSP_LIMIT and session_type = BIDDER 
Set LOCAL.SENSE_CODE to X'08050001' (bidder session limit will be exceeded). 
Otherwise 
Set LOCAL.SENSE_CODE to X'00000000' (session limit will not be exceeded). 


If LOCAL.SENSE_CODE = x'00000000' then 

Return with a value of FALSE (session limit will not be exceeded). 
Else 

Return with a value of TRUE (session limit will be exceeded). 
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PREPARE_TO_SEND_BIND 


FUNCTION: Get the address (LFSID structure) for the session. Create a half-session 
process. Reserve buffers for the session. 


INPUT: LULU_CB control block 


OUTPUT: ASSIGN_LFSID record sent to ASM; HS_ process created; if an error occurs, 
LOCAL .SENSE_CODE set 


Referenced procedures, FSMs, and data structures: 


RESERVE_CONSTANT_BUFFERS page 4-84 
LULU_CB page 4-90 
ASSIGN_LFSID page A-25 
ASSIGN_LFSID_RSP page A-26 
LOCAL page 4-89 
ASM T2.1 Node Reference 


Create an ASSIGN_LFSID record. 

Set ASSIGN_LFSID.PATH_CONTROL_ID to LULU_CB.PATH_CONTROL_ID. 
Set ASSIGN_LFSID.SM_PROCESS ID to this LU's identifier. 

Set ASSIGN_LFSID.PROCESS_ID_TYPE to SM. 

Send ASSIGN_LFSID to ASM. 


Receive ASSIGN_LFSID_RSP from ASM. 
If ASSIGN_LFSID_RSP.SENSE_CODE is not X'00000000' then (ASM couldn't assign LFSID) 
Set LOCAL.SENSE_CODE to ASSIGN_LFSID_RSP.SENSE_CODE. 
Else (LFSID is assigned) 
Set LULU_CB.LFSID to ASSIGN_LFSID_RSP.LFSID. 
Create this half-session's process. 
Call RESERVE_CONSTANT_BUFFERS(LULU_CB) to adjust the permanent 
buffer pool, and to get a demand buffer for the UNBIND 
(page +-84). 
Destroy ASSIGN_LFSID_RSP record. 
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PROCESS_ABEND_NOTIFICATION 


FUNCTION: Process an abend notification record from a child process (RM or HS). 


If HS abends, the FSM is called to clean up the session for the HS (if that 
session still exists). 


If RM abends, the FSM is called once for each active or pending-active session 
known to SM, to clean up all of them; after that, SM itself abends. 


INPUT : ABEND_NOTIFICATION record 


OUTPUT: None 


Referenced procedures,» FSMs, and data structures: 


LOCAL page 4-89 
LULU_CB page 4-90 
FSM_STATUS | page 4-86 
ABEND_NOTIFICATION page A-25 Pom 
Select based on ABEND_NOTIFICATION.ABENDING_PROCESS parameter: \ | 
When RM_PROCESS_ VARIABLE (RM process abends ) ae 
For each active and pending session 
(1.e., for each LULU_CB in LOCAL.LULU_CB_LIST) 
Call FSM_STATUS(ABEND_NOTIFICATION, LULU_CB) (page 4-86). 
When HS_PROCESS VARIABLE (HS process abends) 
Determine which LU-LU session is to be terminated by searching through 
the LOCAL.LULU_CB_LIST control block list for an LULU_CB with a half-session 
identifier (HS_ID) matching that of the half-session identifier in the 
ABEND_NOTIFICATION record (ABEND_NOTIFICATION.PROCESS ID). 
If the LULU_CB is located then 
Call FSM_STATUS( ABEND_NOTIFICATION, LULU_CB) (page 4-86). ca 
he 


PROCESS_ABORT_HS 


FUNCTION: Process an ABORT_HS record received from LU-LU half-session. 


If the ABORT_HS record points to a Known session, call the FSM to perform the 
session deactivation. Otherwise (ABORT_HS does not correlate to any session); 
ABORT_HS 1s ignored. This situation can occur when SM has already destroyed 


HS, but ABORT_HS is still waiting on the queue. 
INPUT: ABORT_HS record 


OUTPUT: None 


NOTE: A half-session cannot send ABORT_HS until it is initialized. 


Referenced procedures,» FSMs, and data structures: 


FSM_STATUS page 4-86 
LOCAL page 4-89 
ABORT_HS page A-9 
LULU_CB page 4-90 


Determine which LU-LU session is being aborted by searching through the 
LOCAL.LULU_CB_LIST control block list for an LULU_CB with a half-session 
identifier (HS_ID) matching that of the half-session that sent the ABORT_HS 
record (ABORT_HS.HS_ID). 

If the LULU_CB is located then 

Call FSM_STATUS( ABORT_HS, LULU_CB) (page 4-86). ( 
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PROCESS_ACTIVATE_SESSION 


FUNCTION: Process an ACTIVATE_SESSION record received from RM. That includes checking 
for a session limit to be exceeded (since RM does not Know whether the session 
limit is exceeded when it sends ACTIVATE_SESSION to SM), creating and initial- 
izing of the LULU_CB control block, getting an FQPCID for the session from SS; 
and sending an INIT_SIGNAL record to SS. 


INPUT : ACTIVATE_SESSION record 


OUTPUT: LULU_CB created and initialized, ACTIVATE_SESSION record and LULU_CB passed 
to the FSM 


Referenced procedures, FSMs, and data structures: 


LU_MODE_SESSION_LIMIT_EXCEEDED page 4-72 
BUILD_AND_SEND_ACT_SESS_RSP_NEG page 4-58 
INITIALIZE _LULU_CB_ACT_SESS page 4-70 
GET_FQPCID page 4-70 
FSM_STATUS page 4-86 
ACTIVATE_SESSION page A-20 
PARTNER_LU page A-2 

MODE page A-~3 

LULU_CB page 4-90 

SS T2.1 Node Reference 


Locate the PARTNER_LU and MODE control blocks using the LU_NAME and MODE_NAME from 
the passed ACTIVATE_SESSION record. 


If LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE; 
ACTIVATE_SESSION.SESSION_TYPE 5 
state_condition(AT_LEAST_INIT_SENT)) then (page 4-72). 
(The number of active and pending-active sessions is already 
equal to the limit set for this [partner LU, mode] pair) 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( ACTIVATE_SESSION.CORRELATOR, RETRY ) 
(page 4-58). 


Else (a session limit is not exceeded) 
Create an LU-LU control block (LULU_CB) and initialize its fields. 
Call GET_FQPCID(LULU_CB) (page 4-70); 
get FQPCID and save in LULU_CB. 
Call INITIALIZE_LULU_CB_ACT_SESS( ACTIVATE_SESSION, LULU_CB) 
(page 4-70). 
Call FSM_STATUS( ACTIVATE_SESSION, LULU_CB) (page 4-86). 
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PROCESS BIND_RQ 


FUNCTION: Check BIND for semantic and state errors, create a half-session process, 
reserve required buffers. If no errors occur, build and send a +RSP(BIND), 
update and save active session parameters, and initialize the half-session. 


MU record containing BIND 


Before passing a BIND to SM, the address space manager checks that the length 
of the BIND RU corresponds to the lengths of all fields in the BIND. If not, 
the BIND is rejected with the appropriate sense data. ASM also checks that 
the total length of the Structured User Data subfields field in the BIND cor- 


responds to the lengths of the individual subfields, that the lengths of the 
NS PLU and SLU Name fields do not exceed 17 bytes, the length of the URC field 
does not exceed 12 bytes, the length of the data portion of the FQPCID control 
vector is between 9 and 26 bytes,» and that at least one control vector is 
present in the BIND if the Control Vector Included indicator in the BIND is 
set to l. 


OUTPUT : If an error is found, an UNBIND or a -RSP(BIND) is sent to ASM; if no error 
is found, LULU_CB is created and initialized, the half-session process is cre- 
ated and initialized, the appropriate buffers are reserved, the SESSION_TYPE 
and SESSION_ID parameters in LULU_CB are updated as a result of the BIND nego- 
tiation, and a +RSP(BIND) is sent to ASM. 


Referenced procedures, FSMs» and data structures: 


BIND_RQ_STATE_ERROR | page 4-52 
INITIALIZE _LULU_CB BIND page 4-71 
RESERVE_VARIABLE_BUFFERS page 4-84 
RESERVE_CONSTANT_BUFFERS page 4-84 
CLEANUP_LU_LU_SESSION page 4-67 
BUILD_AND SEND_INIT_HS page 4-61 . 
BUILD AND SEND_UNBIND_RQ ‘page 4-65 oo 
BUILD BIND_RSP_POS | page 4-67 ( 
BUILD AND SEND_BIND_RSP_NEG page 4-60 ~~ 
FSM_STATUS page 4-86 
LOCAL page 4-89 
MU page A-29 
BIND_RQ RCV, see MU page A-29 
MU_NEW, see MU page A-29 
LULU_CB page 4-90 
PARTNER_LU page A-2 
ASM T2.1 Node Reference 
Check BIND request for semantic errors and if an error exists, oo 
set LOCAL.SENSE_CODE to the sense data reflecting the error. ( , 
Semantic errors are field content errors (e.g., a field does not 


contain an allowable value). These errors are state-independent. 


Call BIND_RQ_STATE_ERROR(MU) (page 4-52) 
to check for state errors. If an error is found, LOCAL.SENSE_CODE 
contains the sense data indicating the type of error. 


If no errors are found then 
Set PARTNER_LU.ACTIVE_SESSION_PARAMETERS.PARALLEL_SESSIONS = 
BIND _RQ_RCV.PARALLEL_SESSIONS. 
Create an LULU_CB control block and initialize its fields. 
Call INITIALIZE_LULU_CB_BIND(MU, LULU_CB) (page 4-71). 
Create LU-LU half-session with unique identifier (save identifier in 
LULU_CB.HS_ID). 
Call BUILD_BIND_RSP_POS(MU, LULU_CB, MU_NEW_PTR) (page 4-67). 
Call RESERVE_CONSTANT_BUFFERS(LULU_CB) to adjust the permanent buffer pool 
and to get a demand buffer for an UNBIND (page 4-84). 
If buffers were gotten then 
Call RESERVE_VARIABLE_BUFFERS(LULU_CB, BIND_RQ_RCV) 
to reserve pacing buffers for the session (page 4-84). 


If all buffers were gotten then “> 
Save a negotiated 8-byte session identifier 1 LULU_CB.SESSION_ID. 
Call BUILD_AND_SEND_INIT_HS(LULU_CB, first 26 bytes of negotiated BIND image) © — 

(page 4-61). 
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If no errors are found during the BIND processing and all required buffers 
are available then 

Send MU_NEW containing a positive RSP(BIND) to ASM. 

Call FSM_STATUS(MU_NEW, LULU_CB) (page 4-86). 


Else (there are errors, session will not be brought up) 
If the FQPCID control vector is present in the BIND then 
Call BUILD_AND_SEND_UNBIND_RQ(MU, CLEANUP type, LOCAL .SENSE_CODE ) 
(page 4-65). | 
Else (FQPCID is not present in BIND or 
errors in BIND do not allow checking whether it is present or not) 
If a demand buffer was gotten for the RSP(BIND) then 
Call buffer manager( FREE_BUFFER, buffer address) to free 
the demand buffer (Appendix B). 
Call BUILD_AND_SEND_BIND_RSP_NEG(MU) (page 4-60). 
If LULU_CB control block was created for the session then 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


PROCESS_BIND_RQ 
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PROCESS_BIND_RSP 


FUNCTION: Check if the received RSP(BIND) correlates with the previously sent BIND. If 
it does, delete pending random data used in LU-LU verification for the session 
(if present) and after additional processing (in case of a positive response) 
call the FSM. If it does not correlate, the RSP(BIND) is considered to be a 


stray one and is ignored (no action taken). 
INPUT: MU record containing the RSP(BIND ) 
OUTPUT: If the RSP(BIND) correlates and LU-LU verification is active for the session, 


the corresponding random data needed for the verification is removed from the 
list of pending random data. 


Referenced procedures > FSMs » and data structures: 


CORRELATE_BIND_RSP page 4-68 
RESERVE_VARIABLE_BUFFERS page 4-84 
BIND_RSP_STATE_ERROR page 4-54 | 
BUILD_AND_SEND_INIT_HS page 4-61 es 
FSM_STATUS page 4-86 

LOCAL page 4-89 Se 
LULU_CB page 4-90 

MU page A-29 
BIND_RSP_RCV, see MU page A-29 

PARTNER_LU page A-2 


Call CORRELATE_BIND_RSP(MU) (page 4-68). 
to check whether a RSP(BIND) correlates to an outstanding BIND. 
If it correlates then 
Set PARTNER_LU.ACTIVE_SESSION_PARAMETERS.PARALLEL_SESSIONS = 
BIND_RSP_RCV.PARALLEL_SESSIONS. 
Remove an entry from the list of pending random data, if the random data 


for this session is there. ( 
If the RSP(BIND) is positive and no length errors were found while , 
correlating it to a previously sent BIND then eye 
Check RSP(BIND) for semantic errors and if an error exists, 
set LOCAL.SENSE_CODE with the sense data reflecting error. 
Semantic errors are field content errors (e.g., a field does not 
contain an allowable value). These errors are state-independent. 
Call BIND_RSP_STATE_ERROR(MU, LULU_CB) (page 4-54) 
to check for state errors. If an error is found, LOCAL.SENSE_CODE 
contains the sense data indicating the type of error. 
If no errors were found then per, 
Call RESERVE_VARIABLE_BUFFERS(LULU_CB, BIND_RSP_RCV) to reserve 
buffers for this session (page 4-84). Ne oy 
Call BUILD_AND_SEND_INIT_HS(LULU_CB, first 26 bytes of negotiated BIND image) 
(page 4-61). 


Call FSM_STATUS(MU(RSP(BIND)), LULU_CB) (page 4-86). 


4-78 SNA LU 6.2 Reference: Peer Protocols 


PROCESS_CINIT_SIGNAL 


C PROCESS_CINIT_SIGNAL 


FUNCTION: Process a received CINIT_SIGNAL record. First, this signal must be correlated 
with a previously sent INIT_SIGNAL record. The correlation is based on the 
value of FQPCID. If the correlation fails, the session has already been 
brought down by RM and a SESSEND_SIGNAL record is built and sent to SS. 


Otherwise (1.e., CINIT_SIGNAL is correlated to a pending-active session), the 
session count is checked, the link buffer size is checked to be sufficiently 
large, LULU_CB is initialized with the additional parameters received in the 
CINIT_SIGNAL record, LFSID is obtained, the half-session process is created, 
and the buffers for the session are reserved. If no errors are found, the 
BIND is sent. 


INPUT: CINIT_SIGNAL record 
OUTPUT: LULU_CB updated, SESSEND_SIGNAL sent if the CINIT_SIGNAL record could not be 
correlated to a previously sent INIT_SIGNAL, a BIND sent if no errors are 
found 
C- Some of the buffers for the session cannot be obtained before the RSP(BIND) is 


received because the lengths of these buffers depend upon the negotiated RU 
sizes and window sizes (see Figure 4-10 on page 4-32). 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_BIND_R@Q page 4-59 
LU_MODE_SESSION_LIMIT_EXCEEDED page 4-72 
PREPARE_TO_SEND_BIND page 4-73 
FSM_STATUS page 4-86 
CINIT_SIGNAL page A~-23 
INIT_SIGNAL page A-23 
—o PARTNER_LU page A-2 
C ‘ MODE page A-3 
sf LULU_CB page ¢-90 
LOCAL page 4-89 
SESSEND_SIGNAL page A-24 
SS T2.1 Node Reference 


Try to correlate CINIT_SIGNAL to a previously sent INIT_SIGNAL 
using the FQPCID parameter. 


If a CINIT_SIGNAL does not correlate with any outstanding INIT_SIGNAL then 
Create a SESSEND_SIGNAL record. | 
Set SESSEND_SIGNAL.SENSE_CODE to X'00000000' (sense data is immaterial in this case). 


je Set SESSEND_SIGNAL.FQPCID to CINIT_SIGNAL.FQPCID. 
ce Set SESSEND_SIGNAL.PATH_CONTROL_ID to CINIT_SIGNAL.PATH_CONTROL_ID. 
Send a SESSEND_SIGNAL record to SS. 
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Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, | 
LULU_LCB.SESSION_TYPE, Ne 
state_condition(AT_LEAST_BIND_SENT)}) (page 4-72) 
to check whether session limit is exceeded. Count only active sessions and those 
pending-active sessions where BIND has already been sent. If error 
is found, the called routine sets LOCAL.SENSE_CODE. 

(BIND has a priority over CINIT_SIGNAL, which, in turn; has a priority over 
ACTIVATE_SESSION. ) 

Check whether the link buffer size is sufficiently large 
to satisfy the lower bound value for the RU sizes 
specified in the MODE control block. 

Check if an active session already exists with this partner, 
and that the partner supports parallel sessions. If error is 
found, set LOCAL.SENSE_CODE to X'08050000'. 


Else (CINIT_SIGNAL correlated, a pending session is identified) | (~ 


If no errors were discovered when the above checks were made then 
Call PREPARE_TO_SEND_BIND(LULU_CB) (page 4-73) 
to initialize additional fields in LULU_CB, 
obtain LFSID, create a half-session process, 
and get buffers (see Note). 


—_ 
If all is ready to send a BIND (1.e., no errors found) then mec 
Call BUILD_AND_SEND_BIND_RQ(LULU_CB) (page 4-59). = 
Call the FSM whether or not an error was found while processing a cor- 
related CINIT_SIGNAL record. The FSM will take appropriate action 
depending upon whether or not LOCAL.SENSE_CODE is set to x'00000000'. 
Call FSM_STATUS(CINIT_SIGNAL » LULU_CB ) (page 4-86). 
-_ 
~ @ 
A eee 


PROCESS DEACTIVATE_SESSION 


FUNCTION: Process’ a DEACTIVATE_SESSION record received from RM. 


INPUT: DEACTIVATE_SESSION record 
OUTPUT: If the DEACTIVATE_SESSION record points to a Known session, call the FSM to 
deactivated that session. 
/ 
\ : 
Referenced procedures, FSMs, and data structures: “Nee 
FSM_STATUS page 4-86 
DEACTIVATE_SESSION page A-21 
LULU_CB page 4-90 


If RM is deactivating a pending-active session (DEACTIVATE_SESSION.STATUS = 
PENDING) then . 
Attempt to locate the LU-LU half-session control block (LULU_CB) using the 
DEACTIVATE_SESSION.CORRELATOR field. 


Else (RM is deactivating an active session--from its perspective) 
Attempt to locate the LU-LU half-session control block (LULU_CB) using the 
DEACTIVATE_SESSION.HS_ID field. 


If an LULU_CB has been located then 
Call FSM_STATUS( DEACTIVATE_SESSION, LULU_CB) (page 4-86). 
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PROCESS_INIT_HS_RSP 


a 
vA 


FUNCTION: Process an INIT_HS_RSP record received from a half-session. 


INPUT : INIT_HS_RSP record 


OUTPUT: If the INIT_HS_RSP record points to a Known session, call the FSM to Cos 
the session activation 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-86 
INIT_HS_RSP page A-10 
LULU_CB page 4-90 


Attempt to locate the LU-LU half-session control block (LULU_CB) associated 
with the half-session that sent the INIT_HS_RSP. Search the list of LULU_CBs 
for one with a half-session identifier (HS_ID) matching that of the half-session 
= the INIT_HS_RSP was received from. 
sy If an LULU_CB is located then 
Call FSM_STATUS(INIT_HS_RSP, LULU_CB) (page 4-86). 


PROCESS_INIT_SIGNAL_NEG_RSP 


FUNCTION: Process a received INIT_SIGNAL_NEG_RSP record from the SS component of the 
control point. 


‘ If an outstanding request to activate a session that corresponds to this 
ae record from SS is found, call FSM in order to terminate 1t. 


INPUT: INIT_SIGNAL_NEG_RSP record 


OUTPUT: If an outstanding request to activate a session can be found that correlates 
‘with the INIT_SIGNAL_NEG_RSP record, call the FSM to terminate the session. 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-86 

| INIT_SIGNAL_NEG_RSP page A-23 

a INIT SIGNAL page A-23 

C LULU_CB page 4-90 
4 ss T2.1 Node Reference 


Attempt to correlate the INIT_SIGNAL_NEG_RSP with a sent INIT_SIGNAL. 
Search for an LULU_CB control block where LULU_CB.FQPCID = INIT_SIGNAL_NEG_RSP.FQPCID. 


If the received record is correlated successfully then 
Call FSM_STATUS(INIT_SIGNAL_NEG_RSP, LULU_CB) (page 4-86). 
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PROCESS_LFSID_IN_USE 


FUNCTION: 


INPUT: 


OUTPUT : 


Process a received LFSID_IN_USE record. This record is sent to SM by ASM so 
that ASM will know whether a given (LFSID, PATH_CONTROL_ID) pair is currently 
in use. ASM must Know before it sends a BIND to an appropriate LU. If the 
pair is in use, ASM will hold the BIND in order to avoid certain race condi- 


tions. 


LFSID_IN_USE record 


LFSID_IN_USE_RSP record to ASM 


Referenced procedures, FSMs, and data structures: 


LFSID_IN_USE page A-26 
LFSID_IN_USE_RSP page A-25 
ASM T2.1 Node Reference 


Find an active or pending-active session with a given (LFSID, PATH_CONTROL_ID) pair. 


Create an LFSID_IN_USE_RSP record. 
Set LFSID_IN_USE_RSP.PATH_CONTROL_ID to LFSID_IN_USE.PATH_CONTROL_ID. 
Set LFSID_IN_USE_RSP.LFSID to LFSID_IN_USE.LFSID. 


If a session with a given (LFSID, PATH _CONTROL_ID) pair was found then 


Set LFSID_ 


Else 


Set LFSID_ 


IN_USE_RSP.ANSWER to YES. 


IN_USE_RSP.ANSWER to NO. 


Send the LFSID_IN_USE_RSP record to ASM. 


PROCESS_MU 


FUNCTION: 
INPUT: 


OUTPUT : 


Process an MU record. 


MU containing BIND, RSP(BIND), or UNBIND 


MU is forwarded to the appropriate procedure. If the buffer holding the MU is 
not reused by SM, the buffer is freed. 


Referenced procedures, FSMs, and data structures: 


PROCESS_BIND_RQ page 4-76 
PROCESS _BIND_RSP page 4-78 
PROCESS _UNBIND_RQ page 4-83 
MU page A-29 


Select based on MU.HEADER_TYPE 
When BIND_RQ_RCV 
Call PROCESS BIND_RQ(MU) (page 4-76). 
When BIND_RSP_RCV 
Call PROCESS _BIND_RSP(MU) (page 4-78). 
When UNBIND_RQ_RCV 
Call PROCESS _UNBIND_RQ(MU) (page 4-83). 


If buffer holding the MU was not reused while processed then 
Call buffer manager( FREE_BUFFER, MU pointer) to free the MU buffer. 
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PROCESS _SESSION_ROUTE_INOP 


FUNCTION: Process a SESSION_ROUTE_INOP record received from ASM. 


INPUT: SESSION_ROUTE_INOP record 


OUTPUT: == The FSM is called for each session using the path control that has failed. 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-86 
SESSION_ROUTE_INOP page A-24 
LULU_CB page 4-90 


Reset all LU-LU sessions that are using the path control process that failed. 
This is done by locating all the LU-LU session control blocks (LULU_CBs) 
that have a path control identifier (PC_ID) matching that of the path 
control process that failed. For each LULU_CB located, 

Call FSM_STATUS(SESSION_ROUTE_INOP, LULU_CB) (page 4-86) 
to reset that session. 


PROCESS_UNBIND_RQ 


FUNCTION: Process a received UNBIND. SM always receives the entire UNBIND MU, since the 
PIU is not longer than 99 bytes and thus no reassembly by the ASM is needed. 
If a received UNBIND correlates to one of the active or pending-active ses- 


sions, the FSM is called to clean up the session. 
INPUT: MU record containing UNBIND 


OUTPUT: Whether or not UNBIND correlates, a RSP(UNBIND) is sent. 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_UNBIND_RSP | page 4-66 
CORRELATE_UNBIND_RQ page 4-69 
FSM_STATUS | page 4-86 
MU page A-29 
UNBIND_RQ_RCV, see MU page A-29 
LULU_CB page 4-90 


Call CORRELATE_UNBIND_RQ(MU) (page 4-69). 
to check whether an UNBIND correlates with an existing session. 


Call BUILD_AND_SEND_UNBIND_RSP(MU) (page 4-66) to send 
a RSP(UNBIND) regardless of whether UNBIND correlated or not. 
A negative response will be sent if UNBIND was received as an EXR 
or contained length errors. 
Otherwise, +RSP(UNBIND) will be sent. 


If UNBIND correlated to an active or pending-active session then 


Call FSM_STATUS(MUCUNBIND_RQ RCV), LULU_CB) 
(page 4-86) to terminate that session. 
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RESERVE_CONSTANT_BUFFERS 


FUNCTION: Increment the size of the permanent buffer pool. Get a demand buffer for an 
UNBIND. 


INPUT : LULU_CB control block 


OUTPUT: The buffers are reserved. 


Referenced procedures, FSMs,» and data structures: 
LULU_CB page 4-90 
LOCAL page 4-89 


Call buffer manager(ADJUST_BUF_POOL, permanent buffer pool ID, change amount) 
to adjust (increase) the number of buffers in the permanent buffer 

pool. Change amount is set to 1, which means that the size is 

incremented by a value determined by the buffer manager 

(Appendix B). 


as 
If additional buffers are available then ( 
Set LULU_CB.PERM_POOL_ADJUSTED_UP to YES. | Ss 
Call buffer manager(GET_BUFFER, demand, buffer size, no wait) 
to get a demand buffer to build an UNBIND. Buffer size is set 
to the maximum size of an UNBIND RU plus length of MU overhead 
(Appendix B). 


If one of the buffer requests was unsuccessful then 
Set LOCAL.SENSE_CODE to X'0812000D' (insufficient buffers exist 
to activate a session). 
Return. 


RESERVE_VARIABLE_BUFFERS 


FUNCTION: Reserve a dynamic buffer pool, and a limited buffer pool. 


INPUT: LULU_CB, bind image (either BIND_RQ_RCV or BIND_RSP_RCV) 


OUTPUT: Reserve pacing buffers for the session. 


Referenced procedures, FSMs, and data structures: er 
MU page A-29 a 
BIND_RQ_ RCV, see MU page A-29 
BIND_RSP_RCV, see MU page A-29 
LULU_CB page 4-90 
LOCAL page 4-89 
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If BIND_RSP_RCV.ADAPTIVE_PACING = SUPPORTED then 
ae Call buffer manager(CREATE_BUF_POOL, varying dynamic, pool owner, 
C , capacity of pool, buffer size, initial number of buffers) to reserve 
i the dynamic buffer pool for the receive pacing buffers. Pool owner 
is set to LULU_CB.HS_ID, capacity of pool and buffer size are set to 
the negotiated values from the BIND, dynamic pool ID is returned 
by the buffer manager (Appendix B). 
If buffers were reserved then 
Call buffer manager(CREATE_BUF_POOL, limited, pool owner, capacity 
of pool, buffer size) to reserve the limited buffer pool for 
the send pacing buffers. Pool owner is set to LULU_CB.HS_ID; 
capacity of pool and buffer size are set to the negotiated 
values from the BIND, limited pool ID is returned by the buffer 
manager (Appendix B). 
Else 
Call buffer manager(CREATE_BUF_POOL, fixed dynamic, pool owner, 
capacity of pool, buffer size) to reserve the dynamic buffer pool | 
for the receive pacing buffers. Pool owner is set to LULU_CB.HS_ID, 
capacity of pool and buffer size are set to the negotiated values 
from the BIND, dynamic pool ID is returned by the buffer manager 
(Appendix B). 
~s If buffers were reserved then 
C ' Call buffer manager(CREATE_BUF_POOL, limited, pool owner, capacity 
Z of pool, buffer size) to reserve the limited buffer pool for the 
send pacing buffers. Pool owner is set to LULU_CB.HS_ID, capacity 
of pool and buffer size are set to the negotiated values from the 
BIND, limited pool ID is returned by the buffer manager 
(Appendix B). 
If any of the buffer requests were unsuccessful then 
Set LOCAL.SENSE_CODE to X'0812000D' (insufficient buffers exist to 
activate session). 


C UNRESERVE_BUFFERS 


FUNCTION: Unreserve (1.e., releases previously reserved buffers) appropriate buffers for 
the session 


INPUT: LULU_CB, permanent buffer pool ID 
OUTPUT: Buffers are unreserved 
— 
@ If the size of the permanent buffer pool was increased when this 


session was activated then 
Call buffer manager(ADJUST_BUF_POOL, permanent buffer pool ID, change 
amount) to reduce the number of buffers in the permanent buffer pool. Set 
change amount to the value (negative) the permanent buffer pool was 
increased by when this session was activated (Appendix B). 


If a demand buffer for UNBIND was previously reserved then 
Call buffer manager(FREE_BUFFER, UNBIND buffer address) to free the 
demand buffer gotten for the UNBIND (Appendix B). 


The limited buffer pool, and the dynamic buffer pool, will be destroyed 
when the owning HS is destroyed. 
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FSM_STATUS 


This FSM maintains the state of an LU-LU session from initiation through ter- 
mination. State name abbreviations and their meanings are as follows: 


RESET = reset 

PEND CINIT = pending receipt of CINIT_SIGNAL record 

PEND BIND RSP = pending receipt of a RSP(BIND) 

PEND INIT HS’ RSP PLU = pending receipt of INIT_HS_RSP when this LU is a 
PLU 

PEND INIT HS RSP SLU = pending receipt of INIT_HS_RSP when this LU is an 
SLU 

ACTIVE = active 


The record to be processed and the LU-LU half-session control block (LULU_CB). 
These inputs denote RUs, interprocess records (1.e., from HS» RM, SS» or ASM 
[see Appendix Al), results of earlier sense data settings (OK, if 
LOCAL .SENSE_CODE was set to 00000000; NG, otherwise), and session roles (PLU 
or SLU) of the local LU. | 


The output depends upon the state of the FSM and upon the type of the input 
record. LULU_CB can be updated. An MU can be created and sent to ASM. See 
particular output code for the details. 


Error type is “retry” if LOCAL.SENSE_CODE has one of the following sense data 
values (an asterisk means any hexadecimal digit allowed): 


O80 1 «2€3¢3€ 
080 52xx«1% 
0812%*x*x 
O83 7H 
O83 PRHHK 
0842 %H 
0845 xX 
084B «3% 
0856 
085 73% 
BOO 12 
800 2% 
S003 xxx 
8013%**00 
8013%*03 
8013%*04 
8013%*05 
8013%*06 


For any other value of LOCAL.SENSE_CODE error type is "no retry." 
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FSM_STATUS 


Referenced procedures» FSMs, and data structures: 


CLEANUP_LU_LU_SESSION page 4-67 
BUILD_AND_SEND_UNBIND_RQ page 4-65 
BUILD_AND_SEND_INIT_SIG page 4-61 
BUILD_AND_SEND_ACT_SESS_RSP_NEG page 4-58 
BUILD_AND_SEND_PC_HS_DISCONNECT page 4-62 
BUILD_AND_SEND_SESSST_SIG page 4-65 
BUILD_AND_SEND_SESS_ACTIVATED page 4-63 
BUILD_AND_SEND_FREE_LFSID page 4-60 
BUILD_AND_SEND_SESS_DEACTIVATED page 4-64 
BUILD_AND_SEND_ACT_SESS_RSP_POS page 4-58 
LULU_CB page 4-90 
LOCAL page 4-89 
ACTIVATE_SESSION | page A-20 
DEACTIVATE_SESSION page A-21 
ABORT_HS page A-9 

INIT_HS_RSP page A-10 
ABEND_NOTIFICATION page A-25 
MU page A-29 
BIND_RQ_RCV, see MU page A-29 
BIND_RSP_RCV, see MU page A-29 
UNBIND_RQ RCV, see MU page A-29 
UNBIND_RSP_RCV, see MU page A-29 


All MUs sent from this FSM will be in the MU_NEW buffer to distinguish 


them from the MU, which may contain the input signal and will be freed 
after the processing is done. 


MU_NEW, see MU 


INIT_SIGNAL_NEG_RSP 
CINIT_SIGNAL 
SESSION_ROUTE_INOP 


RESET 


STATE NAMES----> 


INPUTS STATE NUMBERS-->/ O1 02 


ACTIVATE_SESSION 


INIT_SIGNAL_NEG_RSP 
CINIT_SIGNAL ,OK 
CINIT_SIGNAL »NG 


/ 


+RSP( BIND ) ,OK 
+RSP( BIND ) »NG 
-RSP(BIND ) 


+INIT_HS_RSP 
-INIT_HS_RSP 


DEACTIVATE_SESSION 


ih a 
oO r ee) 


UNBIND 
SESSION_ROUTE_INOP 1K 
ABORT_HS / 


. 7 Dini 


NX = 

Q 
ie a 
a 


RM_ABEND | 
HS_ABEND 

OUTPUT | FUNCTION 

CODE 


Call BUILD_AND_SEND_INIT_SIG(LULU_CB) (page 4-61). 
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Determine the error type by examining the sense data in the INIT_SIGNAL_NEG_RSP 
record (see Note). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, CLEANUP, X‘'08120000' ) 
(page 4-65). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_PC_HS_DISCONNECT(LULU_CB) (page 4-62). 
Determine the error type by examining the sense data in the RSP(BIND} 
record (see Note). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, error type) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, CLEANUP, X'08120000' ) 
(page 4-65). 
Call BUILD_AND_SEND_SESS_DEACTIVATED(LULU_CB.HS_ID, ABNORMAL_RETRY, X'08120000' ) 
(page 4-64). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Determine the error type by examining the sense data in the UNBIND 
record (see Note). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, FORMAT_OR_PROTOCOL_ERROR, 
INIT_HS_RSP.SENSE_ CODE) (page 4-65). 
Call BUILD_AND_SEND_ACT_SESS RSP_NEG( LULU_CB.CORRELATOR, NO_RETRY } 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Determine the reason for session deactivation. If the UNBIND type is Normal or 
BIND Forthcoming, the reason is NORMAL. If the UNBIND type is Invalid Session 
Parameters, or LU Failure Unrecoverable, or Format or Protocol Error, 
the reason is ABNORMAL_NO_RETRY. 

For all other UNBIND types, the reason is ABNORMAL_RETRY. 

Call BUILD_AND_SEND_SESS_DEACTIVATED( LULU_CB.HS_ID, REASON, 
sense data from UNBIND) (page 4-64). 

Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_SESSST_SIG(LULU_CB) (page 4-65). 
Call BUILD_AND_ SEND SESS ACTIVATED( LULU_CB) (page 4-63). 


Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, RETRY ) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


If LFSID for the session was received but the session activation stopped 
because of an error then 
Call BUILD_AND_SEND_FREE_LFSID(LULU_CB) (page 4-60). 
(This is the only place where 
it has to be done by sending a FREE_LFSID record to ASM. 
If a BIND has already been sent then an instruction to free LFSID goes 
to ASM on an UNBIND or a RSP(UNBIND) MU header. ) 


Determine the error type by examining the sense data that describes 
the condition that prevents session activation (see Note). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, error type) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


M Call BUILD_AND_SEND_ SESS DEACTIVATED( LULU_CB.HS_ID, ABNORMAL_RETRY, X'80020000' ) 
(page 4-64). a 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). ‘ 
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Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, FORMAT_OR_PROTOCOL_ERROR, 
INIT_HS_RSP.SENSE_CODE) (page 4-65). | 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Determine an UNBIND type based on the DEACTIVATE_SESSION.TYPE parameter. 

UNBIND type is NORMAL, CLEANUP, or FORMAT_OR_PROTOCOL_ERROR when 

DEACTIVATE_SESSION.TYPE is NORMAL, CLEANUP, or ABNORMAL; correspondingly. 

Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, UNBIND type, DEACTIVATE_SESSION.SENSE_CODE ) 
(page 4-65). 

Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, FORMAT_OR_PROTOCOL_ERROR; 
ABORT_HS.SENSE_CODE) (page 4-65). 

Call BUILD_AND_SEND_SESS_DEACTIVATED(LULU_CB.HS_ID, ABNORMAL_NO_RETRY, 
ABORT_HS.SENSE_CODE) (page 4-64). 

Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, INVALID PARMS, LOCAL.SENSE_CODE ) 
(page 4-65, LOCAL.SENSE_CODE describes the error 
that was discovered while processing the RSP(BIND)). 

Determine the error type based on LOCAL.SENSE CODE(see Note). 

Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, error type) 


(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_ACT_SESS_RSP_POS(LULU_CB) (page 4-58). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, CLEANUP, X‘08120000' ) 
(page 4-65). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, RETRY) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, FORMAT_OR_PROTOCOL_ERROR; 
ABORT_HS.SENSE_CODE) (page 4-65). 
Determine the error type by examining the sense data in the ABORT_HS 
record (see Note). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-58). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(MU_NEW, FORMAT_OR_PROTOCOL_ERROR; 
ABORT_HS.SENSE_CODE) (page 4-65). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-67). 


Loca DATA STRUCTURES 


¢é 


LOCAL (this control block is accessible by any procedure in SM) 
LULU_CB_LIST list of LU-LU half-session control blocks (page 4-90) 
SENSE_CODE (this field is set with a sense data value whenever an error is found) 
LU_ID (SM process ID) 
PLUNAME 
NAME(primary LU name) 


Chapter 4. LU Session Manager 4-89 


LULU_CB 


porn 
\ 


yor 


ee 
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The LU-LU session control block is used by session manager (SM) to keep information about 
an LU-LU session. One LULU_CB exists for each LU-LU session. 


LULU_CB 


The following fields are always set to the correct value when the 
LULU_CB is created and initialized (independent of what caused it to 
be created). 


LOCAL_PARTNER_LU_NAME: locally Known name for the partner LU i 
FQ_PARTNER_LU_NAME: partner LU's network qualified name 
MODENAME: mode name for this LU-LU session ee 


HALF_SESSION_TYPE: possible values: PRI, SEC 
SESSION_TYPE: possible values: FIRST_SPEAKER, BIDDER 


CORRELATOR field is set when an ACTIVATE_SESSION (from RM) causes the 
creation of the LULU_CB. It is used by RM to correlate ACTI- 


VATE_SESSION_RSP to ACTIVATE_SESSION. 


CORRELATOR 
PATH_CONTROL_ID: path control ID for this session i 
LFSID: local address for this session . | 
TRANSMISSION_PRIORITY: this session's transmission priority a 
HS_ID—this field contains the process identifier for the LU-LU 
half-session process (HS). When the half-session process does not 
exist, this field is set to a null value. 
HS_ID 
FQPCID: this session's Fully Qualified PCID control vector | PX 
PC_CHARACTERISTICS: see page A-32 ( 
SESSION_ID: session instance identifier — 
PERM_POOL_ADJUSTED_UP: indicates whether the permanent buffer 
pool was adjusted for this HS. 
PERM_POOL_ID: permanent buffer pool ID. 
DEM_LIM_POOL_ID: limited buffer pool ID. 
DYNAMIC_POOL_ID: dynamic buffer pool ID. 
SENT_BIND_RQ fields are set when a BIND request is sent. A_ copy of 
the sent BIND RU is saved because it is needed to perform error check- 
ing on the received RSP(BIND). 
SENT_BIND_RQ | 
SNF: TH sequence number of sent BIND (used to correlate RSP(BIND) 
BIND_RQ_RU: saved BIND RU 
RANDOM holds the random data used for LU-LU verification sent toa 
partner LU in BIND or RSP(BIND), and the random data received ina one 


RSP(BIND ). 


RANDOM 
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GENERAL DESCRIPTION 
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Presentation services (PS) is the component 
of the LU with which transaction programs 
interact directly. Each execution instance 
of a transaction program at the LU is served 
by its own PS process. This PS process is 
responsible for processing the transaction 
program's requests for LU services. The 
transaction program requests these services 
by issuing verbs. 


The verbs, along with their supplied (by the 
user) and returned (by the LU) parameters, 
are fully described in SNA Transaction Pro- 
grammer's Reference Manual for LU T pe 6.2, 
which defines both the services that the LU 
provides and a syntax for transaction program 
requests for those services. The basic serv- 
ices are SNA-defined and are provided by all 
LU implementations, but the syntax of 
requests for the services within individual 
implementations are implementation-def ined. 


The services requested by verbs usually 
involve communication over a conversation 
with a transaction program at a remote LU. 
The supplied parameters of a verb therefore 
usually include an identifier of the conver- 
sation for which the verb is being issued. 
The data exchanged by conversing transaction 
programs is carried on a session assigned to 
the conversation. 


PS interacts with various other LU compo- 
nents. The LU resources manager (RM) creates 
PS after receiving an Attach or START_TP 
record. In addition, RM assigns the 
half-sessions to PS for conversation traffic, 
and destroys PS after PS informs RM (via the 
TERMINATE_PS record) that the PS instance can 
be destroyed. To carry out transaction pro- 
gram verb requests, PS exchanges data with 
the half-session that RM _ has previously 
assigned for conversation traffic. PS also 
interacts with the transaction program; in 
this book, the transaction program and PS are 
modeled within the same process, which may 
not be the case in actual implementations. 
The PS instance is driven by the verbs issued 
by the transaction program (TP). 


Throughout the PS chapters, a number of ref- 
erences are made to LU 6.2 verbs» and LU 6.2 
verb parameters. See SNA Transaction Program- 
mer's Reference Manual for LU Type 6.2 for 
detailed information about the verbs and verb 
parameters. 


PS COMPONENT FUNCTIONS 


Figure 5.0-1 on page 5.0-2 shows the compo- 
nents of PS. PS.INITIALIZE loads and calls 
the TP. The TP then issues verbs, which are 
processed by the other PS components. The TP 
ends by returning to PS.INITIALIZE. The 
functions and interactions of the PS compo- 
nents are further described below. 


TP: 


® Interacts directly with local end users 
and resources. 

e Requests LU services (for interaction 
with remote resources) by issuing verbs. 


PS. INITIALIZE: 


e Receives program initialization parame- 
ters (PIP data). 

e Loads and calls the TP. 

e §€6Instructs RM (after the TP completes and 
returns) to destroy this PS process. 


PS .VERB_ROUTER: 


e Checks every verb for compatibility with 
the type of the conversation on which it 
was issued. 

® Routes valid verb-issuances to the appro- 
priate verb-processing component. 


PS.MC, PS.SPS» ...» PS.COPR: 


e Process non-basic verbs that request 
optional special services (these compo- 
nents and their associated services are 
described in separate chapters of this 


book ). 

@ Translate non-basic verbs into basic 
verbs. 

PS .CONV: 


e Processes basic conversation verbs. 

e Checks each basic conversation verb for 
compatibility with the state of the con- 
versation on which it was issued. 

e €6©Performs (in co-operation with, or at the 
request of, other verb-processing compo-— 
nents) all basic conversation services. 


All the components of the PS process (includ- 
ing the transaction program execution 
instance ) interact synchronously (using 
call/return logic). PS may exchange informa- 
tion with other LU components by means of 
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PS.INITIALIZE 


V V Vv Vv 
Resources Manager Half- Half- 
Session Session 


See "Chapter 5.1. Presentation Services--Conversation Verbs" 

See “Chapter 5.2. Presentation Services--Mapped Conversation Verbs" 
See "Chapter 5.3. Presentation Services--Sync Point Services Verbs" 
See "Chapter 5.4. Presentation Services--Control-Operator Verbs" 
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Note: A dashed line denotes a synchronous (1.e., a Call) protocol boundary between components» 
while a solid line denotes an asynchronous (1.e., a Send) protocol boundary. 


Figure 5.0-1. Overview of Presentation Services, Emphasizing PS.INITIALIZE and PS.VERB_ROUTER 


asynchronous interprocess communication (us- DATA BASE STRUCTURE 
ing send/receive logic). 


PS uses several data structures to record & 
information needed to provide services to the 
transaction program. These data structures 
include PS_PROCESS_DATA, the transaction con- 


nad 
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trol block (TCB), and the resource control 
block list (RCB LIST). This chapter 
describes the use of these data structures 
by the PS.INITIALIZE and PS.VERB_ROUTER com- 
ponents. Use of data structures by other PS 
components is described in detail in the cor- 
responding chapters. 


PS PROCESS DATA on page 5.0-24 contains data 
that is accessible by all components of the 
PS process. This data includes pointers to 
lists of shared control blocks, and to single 
control blocks describing the local LU and 
this PS process. These pointers are initial- 
ized using information contained in the 
PS_CREATE_PARMS data structure passed from RM 
when it creates the PS process, and they 
remain unchanged thereafter. 


The transaction control block (TCB, page A-9) 
contains information specific to the trans- 
action program instance, such as the list of 


tion) carried in the Attach, and the security 
profile (see SNA Formats for additional 
information) optionally carried in the 
Attach. The TCB also contains the CONTROL- 
LING_COMPONENT field, which is maintained by 
PS.VERB_ROUTER, and records whether the verb 
was issued by the TP or by a verb-processing 
component (on behalf of the TP). The TCB is 
created by RM when the PS process is created 
and destroyed by RM when the PS process is 
destroyed. 


The resource control block (RCB, page A-6) 
contains information specific to a particular 
resource, such as the state of a conversation 
or the conversation type. One RCB exists for 
each active resource (e.g., for each active 
conversation). The RCB is_ created and 
destroyed by RM at the request of PS as part 
of the processing of the ALLOCATE and DEALLO- 
CATE verbs. Certain fields of the RCB are 
shared between PS and RM, while other fields 


C- resources allocated to it, the security user are used exclusively by PS. 


ID (see SNA Formats for additional informa- 
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Figure 5.0-2. Attach Initialization and Termination of Presentation Services and Transaction Program 
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5.0-4 


INITIALIZATION AND TERMINATION 
(PS. INITIALIZE ) 


The PS.INITIALIZE component performs initial- 
ization and termination of PS and the TP. 
Initialization occurs in response to receipt 
of an Attach from another LU, or to a locally 
initiated start-up request. These are dis- 
cussed individually in the following 
sections. 


Processing an FMH-5(Attach) Request 


Figure 5.0-2 on page 5.0-3 shows the protocol 
boundary flows that are used by PS.INITIALIZE 
for initialization and termination of the PS 
process when the TP is invoked because of 
receipt of an FMH-S(Attach). The steps below 
correspond to the numbers in the figure. 


1. Resources manager receives an Attach for 
a transaction program Known locally by 
the LU. 


2. RM creates the PS process,» passing it 
initialization parameters contained with- 
in the PS_CREATE_PARMS (see page A-27) 
structure, including the LUCB_LIST_PTR, 
the TCB_LIST_PTR and the RCB_LIST PTR. 
These parameters are used to initialize 
the PS_PROCESS_DATA structure. 


3. PS next receives from RM an FMH-5 (At- 
tach), accompanied by the TCB ID of this 
instance of PS, the RCB ID of the initial 
conversation (the conversation on which 
the Attach flowed), and sense data con- 
taining the result of RM's checking of 
the Attach. If the sense data indicates 
no error was found by RM, PS.INITIALIZE 
performs additional checking of the 
Attach. This includes a check of the 
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transaction program's support of the con- 
versation type (e.g., basic or mapped) 
and program initialization parameters 
(PIP data). If the Attach is valid and 
no additional data is contained in the 
MU, PS.INITIALIZE calls the buffer manag- 
er to free the MU buffer. If the Attach 
is in error (as determined by RM or 
PS.INITIALIZE) the conversation requested 
in the Attach is terminated. Depending 
on the error detected, the session may be 
deactivated, or the conversation ended 
with DEALLOCATE TYPE( ABEND_PROG). 


The Attach indicates whether PIP data 
follows. If the Attach is correct, the 
PIP data (if any) is received as a single 
GDS variable, and is then separated into 
a list of individual PIP subfields. This 
flow will occur if PIP data is present 
and the data cannot be contained in the 
MU containing the FMH-5( Attach). 


An execution instance of the transaction 
program named in the Attach is then cre- 
ated. This TP is called with arguments 
of the RCB ID of the initial conversation 
and the list of PIP subfields (if pres- 
ent). 

When the TP completes processing 
(normally or abnormally), it returns to 
PS.INITIALIZE. PS.INITIALIZE terminates 
and deallocates (in an 
implementation-dependent way) the TP's 
remaining active conversations (if any; 


the list of conversations that are still , 


active is found in the RESOURCES LIST of 
the TCB). 


Finally, PS.INITIALIZE sends a TERMI- 
NATE_PS (see page A-17) record to the 
resources manager and waits to be termi- 
nated. On receipt of the TERMINATE_PS 
record, RM destroys the PS process. 
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a 7 
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Figure 5.0-3. START_TP Initialization and Termination of 


Program 
S Processing a START TP request 


Figure 5.0-3 shows the protocol boundary 
flows that are used by PS.INITIALIZE for 
initialization and termination of the PS 
process when the TP is invoked because of 
receipt of a START_TP request. The steps 
below correspond to the numbers in the fig- 
ure. 


1. Resources manager receives a START_TP 
request and begins processing the record. 
This processing includes validating the 
START_TP record, and verifying that the 
correct number of PIP parameters have 
been included. 


2. RM creates the PS process, passing it 
initialization parameters contained with- 
in the PS_CREATE_PARMS structure, includ- 

; ing the LUCB_LIST_PTR, the TCB_LIST_PTR 

a and the RCB_LIST_PTR. These parameters 

are used to initialize the 
PS_ PROCESS DATA structure. 
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PS receives the START_TP from RM; accom- 
panied by the TCB ID of this instance of 
PS, and sense data containing the result 
of RM's checking of the START_TP. All 
checking of the START_TP is completed in 
the resources manager; PS does no addi- 
tional checking. The START_TP includes 
the PIP data to be passed to the trans- 
action program, if any is required. 


PS.INITIALIZE creates an execution 
instance of the transaction program named 
in the START_TP record, calls the trans- 
action program, and passes the list of 
PIP subfields (if present). 
PS.INITIALIZE passes a null RCB ID to the 
transaction program because the START_TP 
request does not have aé_=conversation 
associated with it. 


When the TP completes processing 
(normally or abnormally), it returns to 
PS.INITIALIZE. PS.INITIALIZE terminates 
and deallocates (in an 
implementation-dependent way) the TP's 
remaining active conversations (if any; 
the list of conversations that are still 
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active is found in the RESOURCES LIST of resources manager and waits to be termi- 
the TCB). nated. On receipt of the TERMINATE_PS “ 
7 record, RM destroys the PS process. \ 
6. Finally, PS.INITIALIZE sends a_TERMI- _ 
NATE_PS (see page A-17) record to the 


Any Node Resources Transaction 


Process Manager PS. INITIALIZE Program 


. Attach or START_TP(1) 


1 oo 0 
° . (create PS process[1]) . 
2 e SS SS Se Se er Se >o 
& e e e 
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3 ; premarin do 
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resources manager ) 
Figure 5.0-4. Limited-Instance Transaction Program Processing in Resources Manager 


LIMITED-INSTANCE TP PROCESSING 3. PS receives an Attach or START_TP record 
from RM, accompanied by the TCB ID of 
this instance of PS, and sense data con- 


Figure 5.0-4 shows the processing that occurs taining the result of RM's checks of the 
in the resources manager for initialization Attach or START_TP. PS continues proc- 
of the PS processes when a limited-instance essing the Attach or START_TP. 
TP (one having a limit of n_ concurrent 
instances) is invoked because of receipt of 4. PS.INITIALIZE creates an execution 
an Attach request. The steps below corre- instance of the transaction program named 
spond to the numbers in the figure. in the Attach or START_TP record, calls 
the transaction program, and passes the 
1. Resources manager receives an Attach or list of PIP subfields (if present). 
START_TP request and begins processing PS.INITIALIZE calls this TP with the 
the record. appropriate parameters from the Attach or 
| START_TP. 
2. RM creates the PS process, passing it 
initialization parameters contained with- 5. Resources manager may receive additional 
in the PS_CREATE_PARMS structure, includ- Attaches or START_TP records for the same 
ing the LUCB_LIST_PTR, the TCB_LIST_PTR transaction program. Processing of addi- 
and the RCB_LIST_PTR. These parameters tional requests for the transaction pro- “ ~ 
are used to initialize the gram will continue until the instance 3 F 
PS PROCESS DATA structure. limit n is reached. _* 
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6. RM creates additional instances of PS 
until the instance limit n has’ been 
reached. PS creates and calls (similar 
to the processing above) additional 
instance of the transaction program. 


7. RM queues additional requests for a 
transaction program. once the instance 
limit n has been reached. When an exe- 
cuting instance of the transaction pro- 
gram completes its processing» resources 
manager initiates the oldest queued 
request. 


VERB PROCESSING (PS.VERB_ROUTER } 


PS.VERB_ROUTER routes verbs to the appropri- 
ate PS verb-processing component. It also 
processes type-independent conversation verbs 
such as WAIT and GET_TYPE. The supplied 
RESOURCE parameter of most verbs identifies 
the conversation for which the verb is being 
issued. The value in the RESOURCE parameter 
matches one in TCB.RESOURCES LIST, the list 
of resources allocated to the TP. 


PS.VERB ROUTER also maintains the CONTROL- 
LING COMPONENT field of the TCB. The value 
of CONTROLLING_COMPONENT is TP if the verb 
has been issued directly by the transaction 
program. The value is SERVICE_COMPONENT if 
the verb has been issued by another PS compo- 
nent as part of its verb processing. 


WAIT Verb Processing 


The WAIT verb, unlike most verbs, can be 
issued for multiple conversations in addition 


to being issued for a single conversation. 
It allows a TP to wait until specified condi- 
tions are satisfied ("posted") for any of 
several conversations. WAIT processing 
includes: 


® Checking that all the resource IDs are 
valid and that at least one resource is 
eligible for posting 


® Determining whether a resource is already 
posted (and, if one is» returning imme- 
diately) 


e Awaiting, if no posting condition has 
been satisfied, the arrival of data that 
will cause a resource to be posted 


GET TYPE Verb Processing 


GET_TYPE processing is handled locally in 
PS.VERB_ROUTER by copying the conversation 
type from the appropriate RCB into a returned 
parameter of the verb. 


GET TP PROPERTIES Verb Processing 


GET_TP_PROPERTIES processing is_ handled 
locally in PS.VERB_ROUTER by copying the 
requested information from the appropriate 


control blocks into the returned parameters 
of the verb. 
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HIGH-LEVEL PROCEDURES 


5.0-8 


PS 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 1. 


Referenced pr 
PS P 
DEAL 
PROC 
PROC 
LUCB 
MU 
PS _C 
STAR 
TCB 


Presentation services (PS) provides verb-processing services to a transaction 
Program execution instance (TP). PS invokes, terminates, and is driven by the 
TP; PS and the TP are parts of the same process. 


This procedure receives an initialization record (MU or START_TP) from the 
resources manager (RM) and, based on record types invokes the appropriate pro- 
cedure. If the initialization record is valid, PS invokes the transaction 
Program named in the record. When the TP returns to PS, PS informs’ the 
resources manager that the TP has completed (by calling  DEALLO- 
CATION_CLEANUP_PROC), and waits for a subsequent MU or START_TP. 


PS _CREATE_PARMS record, and an MU or START_TP from RM 


Process data is initialized and the appropriate procedure is called to ini- 
tialize the transaction program. : 


If no additional initiation requests for the same TP (that just terminated) 
can be passed to a PS instance by RM, RM will destroy the instance upon 
receiving its TERMINATE_PS record. 

If no record is present, PS will be suspended until a record is received. 


DEALLOCATION_CLEANUP_PROC sends a TERMINATE_PS record to RM, alerting it to 
the termination of its TP and the reusability of this PS instance. 


ocedures, FSMs, and data structures: 


ROCESS_DATA page 5.0-24¢ 
LOCATION_CLEANUP_PROC page 5.0-18 
ESS_FMHS5 page 5.0-10 
ESS _START_TP page 5.0-11 
page A-1l 
page A-29 
REATE_PARMS page A-27 
T_TP page A-19 
page A-9 


Establish the PS environment. 


Initialize the fields of PS_PROCESS_DATA with the values contained in PS_CREATE_PARMS and 
LUCB_PTR so it points to the LUCB for this LU (identified by PS_CREATE_PARMS.LU_ID), 
TCB_PTR so it points to the TCB for this TP (identified by PS_CREATE_PARMS.TCB_ID). 


PS INITIALIZE is imbedded in the root procedure in the PS_ calling 
tree. 


Do this processing until destroyed by RM (see Note 1). 
Receive record from RM (FMH-5 or START_TP; see Note 2). 
Select based on record from RM: 


When MU 
Call P 


ROCESS_FMH5(MU) (page 5.0-10). 


When START_TP 
Call PROCESS _START_TP(START_TP) (page 5.0-11). 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-183 see Note 3). 
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wee 


PS 


During the processing in this chapter, a number of error conditions 
may be encountered. The following logic executes only if one of the 
detectable errors listed have been recognized. The following error 
condition may be detected: 


e A Cannot-Occur condition (>) that does occur in an FSM 


RM page 3-19 
ABEND_NOTIFICATION page A-25 


Create and initialize an ABEND_NOTIFICATION record indicating PS abended. 
Send the ABEND_NOTIFICATION ‘record to RM. 
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PROCESS _FMH5 


PROCESS_FMH5 


FUNCTION: 


INPUT : 


OUTPUT : 


NOTES: 


L. 


This procedure loads and calls an instance of the transaction program named in 
a received FMH-5( Attach). 


An incoming FMH-5(Attach) request is routed to this procedure to initialize 
the transaction program. As shown in SNA Formats, the FMH-5(Attach) contains 
the name of the transaction program to be invoked and an indicator of whether 
program initialization parameters (PIP data) will accompany the Attach. PROC- 
ESS _FMH5 receives the PIP data (if any) from the half-session, and validates 
fields of the FMH-5( Attach). | 


If the FMH-5(Attach) is valid, PS invokes the transaction program named in the 
FMH-5( Attach). 


If the FMH-5( Attach) contains an error, ATTACH_ERROR_PROC is called. 


MU containing an FMH-5( Attach), SENSE_DATA from RM's Attach checks, and possi- 
bly PIP data following the Attach 


The attached (loaded) TP is passed the RCB_ID representing the conversation 
between the attached program and the attaching program, and PIP data, if pres- 
ent. 


If RM finds the Attach invalid, the Attach is accompanied by 
the MU_WITH_ATTACH) with one of the following values: 


sense data (in 


XY 


X'O80F6051' Security not valid 

*X'10086000' FMH length not correct 

X'10086005" Access Security Information field length invalid 
*%'10086009" Invalid parameter length 

X'1008600B" Unrecognized FMH command 

X'10086011' LUW length invalid 

*%'10086021"' TPN not recognized 

X'10086040' Invalid Attach parameter 

X'084B6031' Transaction program not available—retry 
X'084C0000' Transaction program not available—no retry 
X'10086040' Sync level not supported by LU 

X'10086041' Sync level not supported by TP 


Otherwise, RM's sense data in the MU_WITH_ATTACH = X'00000000'. 


2. As an alternative to invoking the transaction program immediately upon receipt 
of the FMH-5(Attach), PS may optionally await the receipt of data indicating 
end-of-chain before dispatching the transaction program. If the end-of-chain 
indicator cannot be received in a single pacing window, then buffer management 
and pacing would force the TP to be started. Once started, an additional pac- 
ing Window can be used to send more data. 


Referenced procedures, FSMs, and data structures: 


ATTACH_ERROR_PROC page 5.0-15 
INITIALIZE_ATTACHED_RCB page 5.0-20 
PS_ATTACH_CHECK page 5.0-12 
PS_PIP_CHECKS page 5.0-13 
RECEIVE _PIP_FIELD_FROM_HS page 5.0-12 
UPM_EXECUTE page 5.0-22 
TCB page A-9 
RCB page A-6 
MU_WITH_ATTACH, see MU page A-29 
CODE, see SENSE_DATA page 5.0-25 
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PROCESS _FMH5 


Set CODE to the Attach check CODE passed up from RM. 


Find the RCB for the conversation identified by the RCB_ID parameter. 
Call INITIALIZE_ATTACHED_RCB(RCB, MU_WITH_ATTACH) (page 5.0-20). 


Put the MU_WITH_ATTACH in the front of the RCB.HS_TO_PS_BUFFER_LIST. 


If CODE indicates a valid Attach then (continue with PS Attach checks) 
Call PS_ATTACH_CHECK(RCB, CODE) (page 5.0-12). 
If PIP data is expected for the TP then (PIP data follows Attach) 
Call RECEIVE_PIP_FIELD_FROM_HS(RCB, Attach PIP data, CODE) (page 5.0-12). 
Call PS_PIP_CHECKS( Attach PIP data, CODE) (page 5.0-13). 


If CODE indicates a valid Attach then 
Call UPM_EXECUTE( TCB.TRANSACTION_PROGRAM_NAME, RCB.RCB_ID, Attach PIP data) 
(page 5.0-223 see Note 2). 
Else (error with the Attach) 
Call ATTACH_ERROR_PROC(RCB, CODE) (page 5.0-15). 


PROCESS _START_TP 


FUNCTION: This procedure loads and calls an instance of the transaction program named in 
a received START_TP. 


A START_TP request is routed to this procedure to complete the necessary proc- 
essing to initialize the transaction program. The START_TP contains the name 
of the transaction program to be invoked, and any program initialization 
parameters (PIP) data. 


INPUT: START_TP information and the | TCB.TRANSACTION_PROGRAM_NAME (from 
PS PROCESS DATA) 


OUTPUT: The TP is passed the PIP data, if present. The START_TP record is destroyed. 


Referenced procedures, FSMs, and data structures: 


UPM_EXECUTE page 5.0-22 
START_TP page A-19 
TCB page A-9 


Save PIP data from START_TP to pass to UPM_EXECUTE. 
Destroy the START_TP record. 
Call UPM_EXECUTE(TCB. TRANSACTION _PROGRAM_NAME, null RCB_ID, saved PIP data) (page 5.0-22). 
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RECEIVE_PIP_FIELD_FROM_HS 


5.0-12 


RECEIVE_PIP_FIELD_FROM_HS 


FUNCTION: 


OUTPUT: 


NOTE : 


During invocation of the transaction program, this procedure receives a pro- 
gram initialization parameters (PIP data) by issuing a RECEIVE_AND_WAIT verb. 
If this verb issuance succeeds in receiving a complete logical record contain- 
ing a PIP Data GDS variable, the received PIP field is returned. If it 
fails, a protocol violation has been committed by the partner LU; the session 
is deactivated and the transaction program is not invoked. 


The RCB for the TP's initial conversation, the PIP Data GDS variable from the 
half-session, and the current status of the Attach processing contained in 
CODE 


PIP data and the value of CODE indicating if a protocol error has occurred 
This error occurs if the partner indicates in the Attach that PIP data fol- 


lows, but no data follows, or the data that follows is not PIP data,» or the 
PIP data field was truncated. 


Referenced procedures, FSMs, and data structures: 


RECEIVE_AND_TEST_POSTING page 5.1-50 
RCB page A-6 
CODE, see SENSE_DATA page 5.0-25 


Create, initialize, and issue a RECEIVE_AND_WAIT on this conversation with: 
RECEIVE_AND_WAIT.POST_CONDITIONS.FILL set to LL. 
RECEIVE_AND_WAIT.POST_CONDITIONS.MAX_LENGTH set to X'7FFF°. 


Call RECEIVE AND _TEST_POSTING(RCB, RECEIVE AND WAIT verb parameters) (page 5.1-50) to 
get the PIP data to pass to the TP. 


If the DATA parameter of the RECEIVE_AND_WAIT verb contains the complete PIP data 
(see SNA Formats for format) then 
Return the Attach PIP data. 
Else (Error with PIP data; see Note) 


Set CODE to 


*%'1008201D'. 


PS_ATTACH_CHECK 


FUNCTION: 


INPUT : 


OUTPUT: 


This procedure validates additional fields of the received Attach. These 
additional checks are performed only if the Attach checks in RM did not detect 
an error. | 


Attach information (from RM), the current value of CODE (X'00000000'), and 


program initialization parameter (PIP) data from HS. 


CODE remains X'00000000' if no invalid fields are found; otherwise, the appro- 
priate sense data. If all the data is exhausted from the MU containing the 
Attach, this procedure calls the buffer manager to free the MU buffer. 


Referenced procedures, FSMs, and data structures: 


RCB page A-6 
TCB page A-9 
MU page A-29 
CODE, see SENSE_DATA page 5.0-25 
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TS 


| 
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PS_ATTACH_CHECK 


Get the first MU from the RCB.HS_TO_PS BUFFER_LIST. 
Set the TRANSACTION_PROGRAM_NAME to the entry in the TCB that is indicated on the Attach. 
Select, in order, based on the following conditions (of Attach fields): 


If 


Errors that cause the session to be deactivated 


When the Logical Unit of Work Identifier fields are incorrectly specified 
(see SNA Formats for proper format) 
Set CODE to X'10086011'. 


| Errors that cause an FMH-7 to be generated 


When the transaction program does not support the conversation type (Basic or Mapped) 
specified in the Attach 
Set CODE to X'10086034¢'. 


Otherwise (no problems detected). 
Do nothing. 


All data in the MU has been processed, so free the MU buffer. 


all the data in the MU has been processed then 
Save the type field (end-of-chain type) from the MU buffer. 
Call buffer manager (FREE_BUFFER, buffer address). 


PS _PIP_CHECKS 


FUNCTION: This procedure checks if PIP data was required with the Attach and whether the 
number of PIP parameters expected matches the number sent, or if PIP data was 
sent and should not have been sent. If a previous error was detected with the 
Attach (CODE -= %X'00000000'), that value is returned and the PIP checks are 
not performed. 


INPUT: The received PIP data and the current value of code 


OUTPUT: If the current value of CODE is not X'00000000', the error code is returned 
without making the PIP checks; otherwise, the PIP checks are performed with 
CODE remaining X‘'00000000' if no errors are found, or updated to the appropri- 
ate sense data in the case of error. 


Referenced procedures, FSMs;, and data structures: 


TCB page A-9 


TRANSACTION_PROGRAM page A-5 
CODE, see SENSE_DATA page 5.0-25 
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PS PIP_CHECKS 


5.0-14¢ 


Set the TRANSACTION _PROGRAM_NAME to the antcy in the TCB that is indicated on . the Attach. 
Select; in order, based on the following conditions: 


Errors that cause the session to be deactivated 


When CODE indicates a previously detected error 
Keep the value of CODE unchanged. 


Errors that cause an FMH-7 to be generated 


When the TP is configured to require checking the number of PIP fields 
If TRANSACTION_PROGRAM.NUMBER_OF_PIP_SUBFIELDS is 0 and Attach 
indicates PIP data is present then 
Set CODE to X'10086031' (PIP not allowed). 
Else (specific number of PIP fields expected) 
If TRANSACTION_PROGRAM.NUMBER_OF_PIP_SUBFIELDS differs from the number in 
received PIP data, or the Attach indicates PIP data not present then 
Set CODE to X'10086032' (wrong number of PIP fields). 
Else 
If the format of PIP data is invalid then (see SNA Formats for format) 
Set CODE to X'1008201D' (PIP format invalid--protocol violation). 


When the TP is not configured to require checking the number of PIP fields 
If the format of PIP data is invalid then (see SNA Formats for format) 
Set CODE to X'1008201D' (PIP format invalid--protocol violation). 


Otherwise (no problems detected). 
Do nothing. 
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ATTACH_ERROR_PROC 


ATTACH_ERROR_PROC 


FUNCTION: This procedure handles the processing required when an invalid FMH-5 (Attach) 
is received. 


Depending upon the type of Attach error (as reflected in the passed SENSE_CODE — 
parameter), PS either generates an (FMH-7, CEB) or causes the session over 
which the Attach flowed to be deactivated. 


When the Attach contains an error that violates defined protocols, PS sends a 
request to RM indicating that the session is to be deactivated. 


For all other Attach errors, PS first issues a SEND_ERROR record to the 
half-session. PS then creates an FMH-7 error message that contains sense data 
identifying the type of Attach error encountered. END_CONVERSATION_PROC is 
called to instruct RM to terminate the conversation and the PS process. 


INPUT: The RCB_ corresponding to the conversation over which the invalid Attach was 
received, and the sense data specifying the type of Attach error 


OUTPUT: The session is deactivated or an FMH-7 error message is sent to the 
half-session and the conversation is ended. (Error data is optionally logged 
and sent with the FMH-7. } 


Referenced procedures, FSMs, and data structures: 


HS a page 6.0-3 
PS_PROTOCOL_ERROR | page 5.0-20 
GET_END_CHAIN_FROM_HS page 5.1-36 
SEND_ERROR_TO_HS_PROC page 5.1-58 
UPM_ATTACH_LOG page 5.0-22 
END_CONVERSATION_PROC page 5.1-34 
SEND_DATA_BUFFER_MANAGEMENT page 5.1-54¢ 
RCB page A-6 

MU page A-29 
CODE, see SENSE_DATA page 5.0-25 


Select based on the value of CODE: 
When X'1008200E', X'10086000', X'10086005', X'10086009', X‘'10086011', X‘'10086040', 
X'1008201D’ (Deactivate the session) 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, CODE) (page 5.0-20). 
Call END_CONVERSATION_PROC(RCB) (page 5.1-34). 
Otherwise (Generate an FMH-7) 
Call SEND _ERROR_TO_HS PROC(RCB) (page 5.1-58). 
Call GET_END_CHAIN_FROM_HS(RCB) (page 5.1-36). 
Select based on the end-of-chain type received: 
When DEALLOCATE_FLUSH 
Log the error in system error log. 
When DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, PREPARE_TO_RCV_FLUSH 
Call UPM_ATTACH_LOG(CODE, LOG_DATA) (page 5.0-22) to generate log data 
describing the detected Attach error. 
If the log data is non-null then 
Log error in local system error log. 
Put into the send MU an FMH-7 (see SNA Formats for format) indicating that 
log data follows and sense data (from CODE): 1s included. 
Call SEND_DATA_BUFFER_MANAGEMENT( Error log GDS variable, RCB) (page 5.1-54). 
(See SNA Formats for Error log GDS format. } 
Else : 
Put into the SEND_MU an FMH-7 (see SNA Formats for format) indicating that 
no log data follows and sense data (from CODE) is included. 
Set MU.PS_TO_HS.TYPE to DEALLOCATE_FLUSH and send the MU record to HS. 
Call END_CONVERSATION_PROC(RCB) (page 5.1-34). 
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PS VERB_ROUTER 


PS_VERB_ROUTER 


FUNCTION: This procedure receives all verbs issued by the TP and routes them to the 


appropriate PS component (e.g., basic conversation verbs to PS.CONV, and 
control-operator verbs to PS.COPR) for processing. 


INPUT: The current transaction program verb 


OUTPUT: The RESOURCE parameter of the verb is checked to see if it is valid before 


proceeding with additional processing. The return code of the TRANS- 
ACTION_PROGRAM_VERB may be updated to OK or to indicate a detected error. 
Also, the | CONTROLLING_COMPONENT is updated to indicate TP or SERV- 
ICE_COMPONENT. Refer to the PS components that are called from this process 
for the specific outputs. 


As a general rule, basic verbs must be issued on basic conversations. This 
check enforces that rule; however, there are some exceptions. Non-basic 
verb-processing components reside above PS.CONV (see Figure 5.0-1 on page 
5.0-2), and typically issue basic conversation verbs in carrying out the func- 
tions of non-basic verbs. When the TP issues a mapped conversation verb, 
PS.VERB_ROUTER routes the verb to PS.MC. PS.MC begins processing the verb, 
and then, in general, issues one or more basic conversation verbs, which are 
processed by PS.CONV. As an alternative, for performance reasons, mapped 
verbs can be routed directly to the proper PS.CONV procedure to avoid addi- 
tional procedure calls. 


If the TP issues a verb that is incompatible with the specified resource, such 

as a mapped conversation verb specifying a basic conversation, the TP has com- 
mitted a programming error. PS_VERB_ROUTER informs the TP of the error by 
means of a return code. 


Referenced procedures, FSMs, and data structures: 


PS_CONV page 5.1-10 
GET_TP_PROPERTIES_PROC page 5.0-18 
WAIT_PROC page 5.0-19 
PS_MC page 5.2-20 
PS_COPR | | page 5.4-32 
PS_SPS page 5.3-35 
RCB page A-6 
A-9 


TCB page 


Select based on type of the TP verb issued: 


Verbs Processed by Presentation Services for Conversations 


When ALLOCATE 


Call PS_CONV(verb parameters ) (page 5.1-10). 


When CONFIRM, CONFIRMED, DEALLOCATE, FLUSH, GET_ATTRIBUTES, POST_ON_RECEIPT, 
PREPARE_TO_RECEIVE, RECEIVE_AND_WAIT, RECEIVE_IMMEDIATE, REQUEST _TO_SEND, 
SEND_DATA, SEND_ERROR, or TEST | 


If the supplied RESOURCE parameter of the verb identifies a conversation assigned 
to this transaction (1.e., occurs in TCB.RESOURCES LIST), then 
Find the RCB for the conversation identified by the supplied RESOURCE parameter. 
If the RCB.CONVERSATION_TYPE is BASIC_CONVERSATION or 
(the RCB.CONVERSATION_TYPE is MAPPED_CONVERSATION and 

TCB.CONTROLLING_COMPONENT is SERVICE_COMPONENT) (see Note 1) then 
Call PS_CONV(verb parameters) (page 5.1-10). 

Else (see Note 2) 
Set the RETURN_CODE of the verb to PROGRAM_PARAMETER_CHECK. 
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PS _VERB_ROUTER 


C j Verbs Processed by Presentation Services for Mapped Conversations 


When MC_ALLOCATE 
Call PS_MC(verb parameters) (page 5.2-20). 
When MC_CONFIRM, MC_CONFIRMED, MC_DEALLOCATE, MC_FLUSH, MC_GET_ATTRIBUTES, 
MC_POST_ON_RECEIPT, MC_PREPARE_TO_RECEIVE, MC_RECEIVE_AND_WAIT, 
MC_REQUEST_TO SEND, MC_SEND_DATA, MC_SEND_ERROR, or MC_TEST 
If the verb's supplied RESOURCE parameter identifies a conversation assigned 
to this transaction (i.e., occurs on TCB.RESOURCES LIST), then 
Find the RCB for the conversation identified by RESOURCE. 
If RCB.CONVERSATION_TYPE is MAPPED_CONVERSATION, 
then (it should be, because this verb is a mapped verb) 
Set TCB.CONTROLLING_ COMPONENT to SERVICE_COMPONENT. 
Call PS_MC(verb parameters) (page 5.2-20). 
Set TCB.CONTROLLING_ COMPONENT back to TP. 
Else (see Note 2) 
Set the RETURN_CODE of the verb to PROGRAM_PARAMETER_CHECK. 
Else 
Se, Set the RETURN_CODE of the verb to PROGRAM_PARAMETER_CHECK. 
@ 


Verbs Processed by Presentation Services for the Control Operator 


When INITIALIZE _SESSION_LIMIT, CHANGE_SESSION_LIMIT, RESET_SESSION_LIMIT, SET_LUCB, 
SET_PARTNER_LU, SET_MODE, SET_MODE_OPTION, SET_TRANSACTION_PROGRAM, 
SET_PRIVILEGED_FUNCTION, SET_RESOURCE_SUPPORTED, SET_SYNC_LEVEL_SUPPORTED, 
SET_MC_FUNCTION_SUPPORTED_TP, GET_LUCB, GET_PARTNER_LU, GET_MODE, GET_LU_OPTION, 
GET_MODE_OPTION, GET_TRANSACTION_PROGRAM, GET_PRIVILEGED_FUNCTION, GET_RESOURCE_ SUPPORTED > 
GET_SYNC_LEVEL_SUPPORTED, GET_MC_FUNCTION_SUPPORTED_LU, GET_MC_FUNCTION_SUPPORTED_TP, 
LIST_PARTNER_LU, LIST_MODE, LIST_LU_OPTION, LIST_MODE_OPTION, LIST_TRANSACTION_PROGRAM > 
LIST_PRIVILEGED_FUNCTION, LIST_RESOURCE_SUPPORTED, LIST_SYNC_LEVEL_SUPPORTED, 

* LIST_MC_FUNCTION_SUPPORTED_LU, LIST_MC_FUNCTION_SUPPORTED_TP, PROCESS_SESSION_LIMIT, 
a ) ACTIVATE_SESSION,», or DEACTIVATE_SESSION 
Set TCB.CONTROLLING_ COMPONENT to SERVICE_COMPONENT. 
Call PS_COPR(verb parameters) (page 5.4-32). 
Set TCB.CONTROLLING_ COMPONENT back to TP. 


Type-Independent Conversation Verbs 


When SYNCPT or BACKOUT 
Set TCB.CONTROLLING_COMPONENT to SERVICE_COMPONENT. 
Call PS_SPS (page 5.3-35)}. 
+ Set TCB.CONTROLLING_COMPONENT to TP. 


When GET_TP_PROPERTIES 
Call GET_TP_PROPERTIES _PROC(verb parameters) (page 5.0-18). 


When GET_TYPE 
Set the RETURN_CODE of the GET_TYPE verb to OK. 
If the verb's supplied RESOURCE parameter identifies a conversation 
assigned to this transaction then 
Find the RCB for the conversation identified by RESOURCE. 
Copy RCB.CONVERSATION_TYPE into the verb's returned TYPE parameter. 
Else 
Set the RETURN _CODE of the GET_TYPE verb to PROGRAM_PARAMETER_CHECK. 


When WAIT 
Set TCB.CONTROLLING COMPONENT to SERVICE_COMPONENT. 
Call WAIT_PROC(verb parameters) (page 5.0-19). 
Set TCB.CONTROLLING COMPONENT back to TP. 
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DEALLOCATION_CLEANUP_PROC 


5.0-18 


DEALLOCATION_CLEANUP_PROC 


FUNCTION: This procedure, which manages the destruction of this process, is invoked 
after the TP has ended. It calls UPM_RETURN_PROCESSING on page 5.0-23 to 
deallocate the process's remaining conversations, and sends DEALLOCATE_RCB to 


RM to get rid of RCBs and any other’ resources allocated 
Finally, 1t sends a TERMINATE_PS record to RM. 


INPUT: TCB.RESOURCES_LIST (from PS_PROCESS DATA) 


OUTPUT : DEALLOCATE_RCB and TERMINATE_PS to RM 


Referenced procedures, FSMs, and data structures: 
RM 
UPM_RETURN_PROCESSING 
FSM_CONVERSATION 
TCB 
RCB 
TERMINATE_PS 


Do for each RCB ID on the TCB.RESOURCES LIST. 
Find the RCB for the conversation identified in the RCB ID parameter. 
If the state of FSM_CONVERSATION is not RESET or is not END_CONV then 
Call UPM_RETURN_PROCESSING(RCB ID) (page 5.0-23). 


Send a TERMINATE_PS record to RM. 


GET_TP_PROPERTIES_PROC 


to the process. 


FUNCTION: This procedure handles requests for information about a transaction program. 


Information about the transaction program is retrieved from 


the appropriate 


control blocks and placed in the returned parameters of the GET_TP_PROPERTIES 


verb. 


INPUT : The TCB, LUCB (from PS_ PROCESS DATA), and the GET_TP_PROPERTIES verb 


OUTPUT : GET_TP_PROPERTIES verb's returned parameters containing information about the 
transaction program 


Referenced procedures, FSMs, and data structures: 
LUCB 
TCB 


Set the GET_TP_PROPERTIES returned parameters as follows: 
OWN_TP_NAME to TCB.TRANSACTION_PROGRAM_NAME 5 
OWN_TP_INSTANCE to TCB.TCB_ID, 
OWN_FULLY_QUALIFIED_LU_NAME to LUCB.FULLY_QUALIFIED_LU_NAME , 
SECURITY_PROFILE to TCB.INITIATING_SECURITY.PROFILE, 
SECURITY_USER_ID to TCB.INITIATING_SECURITY.USERID, 
the RETURN_CODE of the GET_TP_PROPERTIES verb to OK. 
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WAIT_PROC 


C 


FUNCTION: 


INPUT : 


* OUTPUT: 
/ 


WAIT_PROC 


This procedure processes WAIT verbs. First, it validates the resources speci- 
fied in the verb's RESOURCE_LIST parameter. While checking this list, this 
procedure creates a sublist of it called TEMP_RESOURCE_LIST. This sublist 
contains only those resources from RESOURCE_LIST that are currently activated 
for posting. Activated for posting means the TP has issued a POST_ON_RECEIPT 
on the conversation (or resource) and the posting has not been satisfied. (If 
none of the resources specified in the supplied RESOURCE_LIST parameter is 
activated for posting, this procedure sets the RETURN_CODE field of the WAIT 
to POSTING_NOT_ACTIVE. ) 


After creating the TEMP_RESOURCE_LIST, this procedure next checks to see if 
any of the resources in the list have already been posted. If none of the 
resources has been posted, this procedure waits for one of the resources to 
become posted. 


WAIT verb parameters, incoming conversation data 


The verb's returned parameters are set as follows. RETURN_CODE indicates 
whether the WAIT completed successfully. If the verb completed successfully, 
RESOURCE_POSTED indicates which resource has been posted. 


Referenced procedures, FSMs,» and data structures: 


TEST_FOR_RESOURCE_POSTED page 5.0-21 

RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 

TCB page A-9 
A-6 


RCB 


Check that all 


page 


resources in the supplied RESOURCE_LIST parameter are validly 


a allocated to this transaction program (1.e., occur in TCB.RESOURCES LIST), 
\ and that at least one of them has posting active. 

a If any resource is invalid then 
Set the RETURN_CODE of the WAIT verb to PROGRAM_PARAMETER_CHECK, and return. 


If no resource 


has been activated for posting then 


Set the RETURN_CODE of the WAIT verb to POSTING_NOT_ACTIVE, and return. 


At this point (since all resources are valid and one or more have 
“posting active"), it is safe to wait for a resource to become posted. 


If some resource is already posted, there is no need to wait. 


} Call TEST_FOR_RESOURCE_POSTED(RCB, RC) (page 5.0-21) 


2 For each resource that has posting active, 


If the returned RC is not UNSUCCESSFUL then 
Set the RETURN_CODE of the WAIT verb to RC, and return. 


Since no active resource is posted yet, wait until one is. 


Initialize RC to UNSUCCESSFUL. 
Do While RC remains UNSUCCESSFUL. 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS( TEMP_RESOURCE_LIST containing list of RCB_IDs) 
(see FUNCTION above for details; page 5.1-51). 
Set RCB to the RCB for the conversation on which the data has arrived. 
Call TEST_FOR_RESOURCE_POSTED(RCB, RC) (page 5.0-21). 
Set the returned RESOURCE_POSTED parameter to RCB.RCB_ID. 
Set the RETURN_CODE of the WAIT verb to the returned value RC. 
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LOW-LEVEL PROCEDURES 


5.0-20 


PS_PROTOCOL_ERROR 


FUNCTION: 


INPUT : 


OUTPUT : 


This procedure processes receive error conditions that require the session to 
be deactivated. 


An UNBIND_PROTOCOL_ERROR record is sent to the resources manager to request 
deactivation of the session that committed the protocol violation. 


The HS ID for the half-session that committed the protocol violation, the 
TCB_ID (from PS_PROCESS_DATA), and the sense data to be sent on the UNBIND 


UNBIND_PROTOCOL_ERROR (to RM) with the TCB ID for this PS process’ and the 
input HS ID and sense data 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
PS_ PROCESS DATA page 5.0-24 
HS_ID page 3-91 
SENSE_CODE, see SENSE_DATA page 5.0-25 
UNBIND_PROTOCOL_ERROR page A-17 


Initialize an UNBIND_PROTOCOL_ERROR record (page A-17) 


with this TCB_ 


ID, HS_ID»y and SENSE_CODE. 


Send the UNBIND_PROTOCOL_ERROR to RM. 


INITIALIZE_ATTACHED_RCB 


FUNCTION: 


INPUT: 


OUTPUT : 


Referenced procedures, FSMs, and data structures: 


RCB 


This procedure initializes the PS.CONV specific fields in the RCB_ for the 
resource specified in the received Attach. The shared fields in the RCB are 
initialized by RM. 

This procedure is invoked when RM forwards Attach information to PS. 


RCB of the conversation and Attach information (received from RM) 


The PS.CONV specific fields in the specified RCB are initialized. RM initial- 
izes all the shared data in the RCB. The states of FSM_CONVERSATION, 
FSM_POST, and FSM_ERROR_OR_FAILURE are initialized to the proper states. The 
receive buffer, HS_TO_PS_BUFFER_LIST of the RCB, is purged. If the conversa- 
tion is MAPPED, the MAPPED fields of the RCB are initialized. 


page A-6 
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INITIALIZE ATTACHED_RCB 


Ro Initialize the RCB fields as follows: 
. CONVERSATION_TYPE to the TYPE value in the Attach; 

= LIMITED_BUFFER_POOL_ID to the ID value in the Attach, 
PERMANENT_BUFFER_POOL_ID to the ID value in the Attach, 
SEND_RU_SIZE to the SIZE value in the Attach, 
POST_CONDITIONS.FILL to LL; 
POST_CONDITIONS .MAX_LENGTH to 0; 
LOCKS to SHORT, 
RQ_TO_SEND_RCVD to NO. 
Purge the receive buffer (RCB.HS_TO_PS_BUFFER_LIST). 


Initialize the states of the FSMs as follows: 
FSM_CONVERSATION to RCV; 
FSM_ERROR_OR_FAILURE to NO_REQUESTS, 
FSM_POST to RESET. 


If RCB.CONVERSATION_TYPE is MAPPED_CONVERSATION then 
Purge the MAPPED receive buffer (RCB.MC_RECEIVE_BUFFER). 
Initialize the RCB fields as follows: 
MC_RQ_TO_SEND_RCVD to NO, 
MAPPER_SAVE_AREA to an implementation-defined value, 
C- MC_MAX_SEND_SIZE according to a implementation-defined algorithm. 


TEST_FOR_RESOURCE_POSTED 


FUNCTION: This procedure determines if the resource corresponding to the passed RCB has 

been posted. Depending on the type of conversation indicated by the RCB, this 

ik procedure issues either a TEST (TEST = POSTED) or an MC_TEST (TEST = POSTED) 
C ) . verb, which is. processed by PS.CONV ("Chapter 5.1. Presentation Serv- 
1ces--Conversation Verbs") or PS.MC ("Chapter 5.2. Presentation Serv- 

ices--Mapped Conversation Verbs"), respectively. The RETURN_CODE field in the 


returned verb indicates whether posting has occurred for the specified conver- 


sation. 
INPUT: ‘The entry in the RCB_LIST corresponding to the resource for which this proce- 
dure is to determine if posting has occurred 
OUTPUT: The return code returned for the issued TEST or MC_TEST verb 
oe Referenced procedures, FSMs, and data structures: 
C : TEST_PROC page 5.1-26 
J MC_TEST_PROC page 5.2-28 
RCB page A-6 


Select based on RCB.CONVERSATION_TYPE: 
When basic 
Create TEST record and initialize as follows: 
RESOURCE is RCB.RCB_ID, TEST is POSTED. 
Call TEST_PROC(TEST verb parameters) (page 5.1-26) to test posting. 
When mapped 
Create MC_TEST record and initialize as follows: 
RESOURCE is RCB.RCB_ID, TEST is POSTED. 
Call MC_TEST_PROC(MC_TEST verb parameters) (page 5.2-28) to test posting. 
Return to the caller the RETURN_CODE from the TEST or MC_TEST verb. 
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UNDEFINED PROTOCOL MACHINES 


ra 


UPM_EXECUTE 


FUNCTION: This UPM loads and executes a transaction program. 


INPUT : The name of the transaction program, the resource ID (to be passed to the 
transaction program), and a list of PIP data (to be passed to the transaction 
program ) 


OUTPUT: None 


ee 
Not defined by SNA 


UPM_ATTACH_LOG . 


FUNCTION: This UPM is invoked upon discovery of an error in an FMH-5 (Attach). It 
returns log data describing the error. This data is logged in the local sys- 
tem error log and is sent back to the conversation partner in an Error-Log GDS 
variable accompanying an FMH-7. 


INPUT: Attach error sense data 


OUTPUT : Log data (may be null) 


Not defined by SNA 


C) 
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UPM_RETURN_PROCESSING 
UPM_RETURN_PROCESSING 


This UPM is invoked when a TP ends and returns to PS without having deallo- 
cated all its resources. It terminates and deallocates a remaining active 
resource in an implementation-specific way. Two of the many ways in which an 
implementation could do this are to: 


e Issue DEALLOCATE TYPE(ABEND_SVC) for the still-allocated resource. 


e Issue DEALLOCATE TYPE(SYNC_LEVEL) if the resource is in SEND state and 


data in PS's send buffer is on a logical record boundary. If the attempt 
to synchronize fails, or the data was not ona logical record boundary, 
then issue DEALLOCATE TYPE( ABEND_SVC). 


Regardless of what other actions are taken, this UPM causes FSM_CONVERSATION 
(page 5.1-65) to enter the reset state. 


INPUT: The RCB_ID of the still-allocated resource 


OUTPUT: See above. 


Not defined by SNA 
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LOCAL DATA STRUCTURES 


5.0-24 


PS_PROCESS_DATA is available to all procedures in the presentation services process. The 
structure is initialized by the PS process (page 5.0-8) and remains unchanged for the 
lifetime of the PS process. | 


PS PROCESS _DATA 


PS PROCESS DATA 
LUCB_LIST_PTR: Pointer to 


LU_ID: ID of this 
LUCB_PTR: Pointer to 
TCB_LIST_PTR: Pointer to 
TCB_ID: ID of this 


TCB_PTR: Pointer to 
RCB_LIST_PTR: Pointer to 


TCB_LIST_PTR: Pointer to the list of TCBs for TP-PS processes at this LU. 


the LUCB_LIST 

PS's LU 

the LUCB for this PS‘'s LU 
the TCB_LIST 

PS 

the TCB for this PS 

the -RCB_LIST of this PS 


TCB_LIST_PTR 


foo, 
RCB_LIST_PTR / 
< 


RCB_LIST_PTR: Pointer to the RCB_LIST for this TP-PS process. 


LUCB_LIST_PTR | 


LUCB_LIST_PTR: Pointer to the list of LUCBs for LUs Known to this LU. 
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SENSE_DATA 


= SENSE_DATA 


SENSE_DATA: 4-byte sense data 
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Peer Protocols 


GENERAL DESCRIPTION 


A PS process handles requests for LU serv- 
ices. A transaction program (TP) execution 
instance makes these requests by issuing 
verbs. The verbs are divided into catego- 
ries, and PS is’ divided into components. 
Each verb-processing component of PS proc- 
esses the verbs of one specific category. 
Presentation services for basic conversations 
(PS.CONV) is the component of PS that proc- 
esses verbs of the basic conversation catego- 
ry. Figure 5.1-1 on page 5.1-2 provides an 
overview of PS, showing the relationship of 
PS.CONV to the other PS components. 


The basic conversation verbs correspond to 
the most basic services provided by the LU. 
Other PS components, such as PS.MC ("Chapter 
5.2. Presentation Services--Mapped Conversa- 
tion Verbs") and PS.COPR ("Chapter 5.4. Pres- 
entation Services--Control-Operator Verbs" } 
use basic conversation verbs in providing 
their higher-level functions. “Open-API" 
implementations may choose to expose only the 
mapped conversation verbs to user-application 
transaction programming, while leaving the 
lower-level basic conversation verbs 
"closed." 


See Chapter 5.0 for an overview of PS and its 
components, and of the relationship of PS to 
the other components of the LU. Refer to SNA 
Transaction Programmer's Reference Manual for 


LU Type 6.2 for a complete description of the 
basic conversation verbs. 


PS.CONV FUNCTIONS 


The functions of PS.CONV include: 


e Requesting the allocation and deallo- 
cation of conversation resources. 


¢ Maintaining and checking the basic con- 
versation state. 


¢ Transferring conversation data between 
the half-session and transaction program 
variables. 


® Tracking logical record lengths. 


COMPONENT INTERACTIONS 


PS.CONV interacts with PS.VERB_ROUTER ("Chap- 
ter 5.0. Overview of Presentation Services"), 


Chapter 5.1. Presentation Services--Conversation Verbs 


the resources manager ("Chapter 3. LU 
Resources Manager"), and one or_ more 
half-session components (“Chapter 6.0. 
Half-Session"). 


All verb service requests are routed through 
PS.VERB_ROUTER, which forwards basic conver- 
sation verbs to PS.CONV. After PS.CONV has 
performed the requested service, control is 
returned to the caller, with updated values 
in those variables that are the verb's 
returned parameters, or in which 1t requested 
a result to be returned. 


PS.CONV interacts with the resources manager 
(RM) to request allocation and deallocation 
of LU resources, such as conversations and 
associated control blocks, and to report pro- 
tocol errors. Since PS.CONV and RM are mod- 
eled as different processes, this interaction 
occurs by means of asynchronous interprocess 
communication (send/receive logic). RM also 
informs PS.CONV if a conversation being used 
by PS.CONV fails for some reason. 


PS.CONV interacts with one half-session proc- 
ess for each active conversation used by 
PS.CONV. Each half-session serves a single 
conversation at a time. Since the TP may 
have active conversations with several part- 
ners simultaneously, PS.CONV may be interact- 
ing with a number of different half-session 
processes. 


PS.CONV interacts with the buffer manager to 
get and free storage used to send and receive 
data. PS.CONV requests a buffer (for an MU) 
from the buffer manager when data must be 
sent. PS.CONV copies the data from the TP 
verb into the buffer before passing the buff- 
er to HS for sending out of the LU. When 
PS.CONV is passed ae buffer (holding an 
inbound MU) from HS, it passes the data as 
requested to the TP. When all the data has 
been passed to the TP, PS.CONV requests the 
buffer manager to free that buffer storage. 


PS.CONV DATA BASE STRUCTURE 


PS.CONV uses a number of control blocks and 
data structures. The most important ones are 
described here. See “Appendix A. Node Data 
Structures" for full details. 
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Vv V V 
Resources Manager Half- 


Session 


Half- 
Session 


See "Chapter 5.2. Presentation Services--Mapped Conversation Verbs" 


2 See "Chapter 5.3. Presentation Services--Sync Point Services Verbs" 
3 See "Chapter 5.4. Presentation Services--Control-Operator Verbs" 


Note: 


Figure 5.1-1. 


5.1-2 


identifier 


A dashed line denotes a synchronous (call/return) protocol boundary between components » 
while a solid line denotes an asynchronous (send/receive) protocol boundary. 


Overview of Presentation Services, 
Conversations 


LU Control Block (LUCB) and Associated Lists 


The LU control block (LUCB--see Figure 5.1-2 
on page 5.1-3) is used by PS.CONV. One LUCB 
exists for each LU in the node. The LUCB is 
identified by the LU ID, which is a unique 
for each LU in the node. Each 
LUCB contains information such as_ the 
network-qualified LU name. 
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Emphasizing Presentation Services 


for Basic 


Associated with each LUCB is a_ TRANS- 
ACTION_PROGRAM_LIST. The TRANS- 
ACTION _PROGRAM_LIST for an LU contains an 
entry for each transaction program Known 
locally by the LU. The information in a 


C) 


TRANSACTION_PROGRAM_LIST entry includes the” ~ 


transaction program name and whether it sup~ 


ports various optional features (e.g.>, syne 


point, mapped conversations). 


oS 


© 


Figure 5.1-2. 


LUCB_LIST 


PARTNER_LU_LIST 


MODE_LIST 


Another list associated with each LUCB is the 
PARTNER_LU_LIST (see Figure 5.1-2 on page 
5.1-3). The PARTNER_LU_LIST contains one 
entry for each potential partner LU of the LU 
represented by the LUCB. The PARTNER_LU 
entry contains information that is fixed for 
the specific partner LU, such as the local 
and network-qualified names of the partner 
LU. 


Associated with each PARTNER_LU entry is a 
MODE_LIST (see Figure 5.1-2), which has one 
entry for each mode name that is defined for 
possible use with the particular partner LU 
name. The MODE entry contains information 
that is fixed on a mode basis, such as the 
mode name and maximum mode session limit. 


Transaction Control Block (TCB) 


The transaction control block (TCB--see Fig- 
ure 5.1-3 on page 5.1-4) contains information 
associated with the combined TP-PS process. 
One TCB exists for each TP-PS process. Each 
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TCB contains a TCB ID, which is a unique 
identifier of the TP-PS process being repres- 
ented by the TCB. The TCB ID is used in all 
communication between the resources manager 
and the PS serving the transaction program. 
For example, when PS sends a record to the 
resources manager, it provides its TCB ID so 
that the resources manager will Know, of all 
the TP-PS processes it manages, which one to 
send a reply to. 


Associated with each TCB 1s the 
RESOURCES_LIST, a list of the resources used 
by the TP-PS process. The RESOURCES LIST has 
one entry for each resource (e.g., for each 
conversation) associated with the transaction 
program. 


PS PROCESS DATA 


PS PROCESS DATA (page 5.0-24) contains data 
that is available to all procedures in the PS 
process. It contains information about this 
particular TP-PS process, such as the LU ID 
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RESOURCES_LIST 


TCB_LIST > } 
TCB1 ait 
TCBn 
Figure 5.1-3. Transaction Control Block (TCB) 
and the pointer to the RCB_LIST. It is ini- conversation does not change until 
tialized by the root procedure of the PS PS.CONV has actually notified the trans- 
process (page 5.0-8) from parameters received action program, even though the _ send 
in PS _CREATE_PARMS. PS_CREATE_PARMS is indication may have arrived from the -~ 
passed to PS from RM when the PS process is half-session sometime earlier. ; 
created. Ni 
THE SEND MU (page A-29) 1s associated with 
the RCB and is used to store data that 
Resource Control Block (RCB) has been generated by verb processing 
(1.e., for the SEND_DATA verb) but that 
has not yet been sent to the 
One resource control block (RCB--see Fig- half-session. 
ure 5.1-4 on page 5.1-5) represents each 
active conversation allocated to a _ trans- FSM_ERROR_OR_FAILURE (page 5.1-67) is a 
action program. The RCBs for all active con- finite-state machine that tracks errors 
versations in an LU are kept in the RCB_LIST. or failures on the conversation associ- 
RCBs are added to or removed from _ the ated with the RCB. The state of 
RCB_LIST by the LU resources manager, at the FSM_ERROR_OR_FAILURE records the receipt~ 
request of PS.CONV. RCBs are also linked to of the error or failure (forwarded fro: 
the RESOURCES LIST for the particular TP-PS RM or HS) until the appropriate notifica-~.— 
process to which they are allocated. The TCB tion can be returned to the TP in verb 
for the process has an associated parameters. 
RESOURCES LIST which contains a list of RCBs 
(specified by the RCB_ID). The list of RCBs FSM_POST (page 5.1-68) is ae finite-state 
represents the resources, such as conversa- machine that tracks the posting condition 
tions, allocated to the process. of a conversation associated with the 
RCB. The state of FSM_POST_ records 
An RCB for a conversation contains informa- whether the conditions specified to sat- 
tion pertaining to a particular conversation, isfy have been (state POSTED) or have not 
such as its resource ID, state, and charac- been (state PEND_POSTED) satisfied. 
teristics (established when the conversation _— 
is allocated). Components of PS will update HS_TO_PS BUFFER_LIST contains a list of MUs ; 
certain fields of the RCB as the conversation that. have been received from the ~~ 
is used. half-session but not yet passed to the 
transaction program. 
The RCB is identified by a unique RCB ID. 
This ID accompanies most transaction program SECURITY_SELECT initially contains the type 
verb issuances (as the RESOURCE parameter) to of end-user verification: NONE, SAME, or 
identify the conversation to which the verb PGM. This value might be downgraded from 
is to be applied. The RCB also contains the PGM to NONE or SAME to NONE (see "Chapter 
TCB ID of its owning TP-PS process, and the 3. LU Resources Manager" for details of 
HS ID of the local half-session that carries when RM downgrades end-user’ verifica- 
the conversation's data. Other fields asso- tion). The Attach is built using the 
ciated with the RCB are discussed in more SECURITY_SELECT value. 
detail below. 
FSM_CONVERSATION (page 5.1-65) is a VERB PARAMETERS 
finite-state machine that tracks the 
state of the conversation associated with 
the RCB. The state of FSM_CONVERSATION The TP requests LU services by issuing verbs. 
is the state of the conversation from the A verb and its parameters are passed as 
viewpoint of the local TP. For example > parameters to PS CONV (page 5.1-10). The“. 
the conversation changes from receive to service requested is identified by the verl . 
send state when the transaction program name and the supplied parameter fields, and~.-” 
is notified by a WHAT_RECEIVED = SEND some results of the service (along with any 
from a receive verb. The state of the other pertinent incoming data) are returned 
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RCB_LIST 


FSM_CONVERSATION 
< 
SECURITY_SELECT 
LT 
V 
FSM_ERROR_OR_FAILURE 
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\ 
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Figure 5.1-4. Resource Control Block (RCB) 


to the TP in the returned parameter fields. 
Each verb issuance has: 


1 e¢ An indicator of which verb is’ being 
ee issued (e.g., ALLOCATE, CONFIRM) 

; ®¢ Some supplied parameters, including (typ- 
ically) an identifier of the conversation 
on which the verb is being issued 

e Some returned parameters, including (typ- 
ically) a return code telling whether the 
requested service was performed success- 
fully 


Some examples of exceptions to these parame- 
ter rules are the following. ALLOCATE does 


ae not supply a conversation ID (although it 
q is does return one), while WAIT supplies a list 
ee of conversation IDs. CONFIRMED and FLUSH do 


not need any returned parameters. The basic 
conversation verbs and their parameters are 
fully described in SNA Transaction Program- 
mer's Reference Manual for LU Type 6.2. 


PS-RM RECORDS 


PS.CONV sends records to RM and receives 
records from RM. PS sends several types of 
records to RM. Each contains a TCB ID iden- 
tifying the PS process that sent the record, 
and possibly additional fields. Records sent 
from RM to PS are usually sent in reply to a 
request sent from PS to RM, as shown in Fig- 
ure 5.1-5. 
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SEND_MU 


CL 


HS_TO_PS_BUFFER_LIST 


PS.CONV Request RM Reply 
ALLOCATE_RCB 
GET_SESSION 
DEALLOCATE_RCB 


RCB_ALLOCATED 
SESSION_ALLOCATED 
RCB_DEALLOCATED 


Figure 5.1-5. PS.CONV Requests and 
Associated RM Replies 


The only exception is CONVERSATION_FAILURE , 
which RM sends unsolicited to PS.CONV when a 
conversation being used by PS.CONV fails. 


PS-HS RECORDS 


PS.CONV sends MUs to ae half-session and 
receives MUs and other records from a 
half-session. 


An MU contains a field, identifying the par- 
ticular type of MU, and additional fields in 
the case of SEND_DATA_RECORD. 
SEND_DATA_RECORD is used to send data and RH 
information to the half-session when the 
local transaction program is in send state 
for the conversation. Included in the 
SEND_DATA_RECORD is the transaction program 
data to be sent and an encoding of the RH 
bits (see SNA Formats) that are to be set by 
the half-session when the data is sent to the 
remote LU. Data to be sent to a half-session 
is added to the existing send MU buffer by 
PS.CONV until the maximum send RU size is 
exceeded, thus forcing the buffer (SEND_MU) 
to be passed to the half-session for trans- 
mission. The transaction program can also 
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issue a verb that forces the data to be 
passed to the half-session for transmission 
(e.g.» CONFIRM, RECEIVE_AND_WAIT, or DEALLO- 
CATE ). 


Other MU types are sent from PS to the 
half-session only when the local transaction 
program is in receive state. These include 
CONFIRMED, used to reply positively to a pre- 
vious CONFIRM record; REQUEST_TO_SEND, used 
to request the send indicator from the part- 
ner transaction program; and SEND_ERROR, used 
to send -RSP(0846) to the partner LU. 


MU and other records can also be sent from HS 
to PS, in which case, the BRACKET_ID field in 
the passed record is used to identify which 
half-session sent the record to PS.CONV. 


TRACKING LOGICAL RECORD LENGTH 


Transaction programs using a basic conversa- 
tion must ensure that the data they exchange 
is formatted into logical records. The 
length of a logical record is given by the 
low-order 15 bits of the first two bytes of 
the record. The high-order bit is the "“con- 
tinuation bit", which is used for GDS vari- 


ables by PS .MC (see “Chapter 5.2. 
Presentation Services--Mapped Conversation 
Verbs"). The value in the Length field 


includes the length of the field itself; thus 
the length value is normally in the range 
2-32767. A length value of O is invalid 
while a length value of 1 is used to indicate 
a PS header (see "Chapter 5.3. Presentation 
Services--Sync Point Services Verbs" for more 
details). 


When sending data, the transaction program is 
responsible for correctly setting the Length 
bytes of each logical record. The amount of 
data sent by a SEND_DATA verb need have no 
relation to a logical record; i.e., the 
transaction program may send partial logical 
records in SEND_DATA verbs, and may include 
multiple logical records in one verb. 


PS.CONV performs some checking of the logical 
record Length field supplied by the trans- 


action program. The value of the Length 
field must be greater than 1, unless 
TCB.CONTROLLING_ COMPONENT = SERV- 


ICE COMPONENT, that is» unless some PS serv- 
ice component (e.g.» PS.MC or PS.SPS) is 
sending a PS header in the record on behalf 
of a transaction program. 


Certain verbs (e.g., CONFIRM) may be validly 
issued only at logical record boundaries 
(1.e., between logical records). PS.CONV 
enforces this rule by remembering how many 
bytes remain to be sent in the current log- 
ical record. SEND_ERROR and  DEALLOCATE 
TYPE(ABEND) are the only verbs that can pre- 
maturely truncate a logical record. 


PS.CONV also tracks the value of the Length 
field for logical records received from the 
partner transaction program. Logical records 
with a Length of 1 are passed to PS_SPS. 
PS.CONV maintains a count of the number of 


SNA LU 6.2 Reference: Peer Protocols 


bytes remaining in the current logical 
record. PS.CONV performs an optional receive 
check to determine if the partner LU has vio- 
lated PS protocols by allowing the partner 
transaction program to invalidly truncate the 
logical record. Only an FMH-7 can validly 
truncate a logical record. 


Finally, when a receive verb is issued speci- 
fying FILL(LL), PS uses the receive count 
remainder (1.e., the number of bytes in the 
logical record not received) to determine how 
many bytes of received data to pass to the 
transaction program. 


MAINTAINING AND CHECKING THE BASIC CONVERSA- 
TION STATE 


PS.CONV maintains the current state of each 
conversation in FSM_CONVERSATION 
5.1-65). As noted earlier, the state of, 


ected 


(page ~-™ 


FSM_CONVERSATION is the state of the conver- 


sation as viewed by the local transaction 
program. 


The state of the conversation may change as a 
result of verbs issued by the transaction 
program; e.g.» PREPARE_TO_RECEIVE changes the 
state from send to receive. These inputs 
have DIRECTION=S in FSM_CONVERSATION. The 
state may also change as a result of data or 
indicators received from the half-session; 
e.g.» receiving the send indicator changes 
the state of the conversation from receive tc 
send. These inputs have DIRECTION=R in. 
FSM_CONVERSATION. 


The current state of the conversation deter- 
mines the verbs that can be validly issued; 
e.g.» a SEND_DATA verb cannot be issued in 
receive state. 


VERB PROCESSING 


are described here. 
Overview of the LU" for more flow diagrams 
corresponding to the processing of these and 
other verbs. 


Verb Checking 


PS.CONV performs a number of send checks on 
verbs issued by the transaction program. 
These include: 


¢ Parameter checks » such as checking that: 


~- The parameters specified on the ALLO- 
CATE are supported by the LU. 

—- The verb conforms to the SYNC_LEVEL 
of the conversation (as specified on 


ALLOCATE ). 
—- The DATA parameter on SEND_DATA con- 
tains a valid Length field (see 


"Tracking Logical Record Length"). 
e State checks, such as checking that: 


GS 


AL fs 
he 


—~ 
Details of PS.CONV's processing of some verbs/ 
See also "Chapter 2.\_. 


— 


a 
. 


ho 


- The verb can be issued in the current 
conversation state (see "Maintaining 
and Checking the Basic Conversation 
State" on page 5.1-6). 

- The transaction program has completed 
the current logical record, if neces- 
sary (see "Tracking Logical Record 
Length" on page 5.1-6). 


ALLOCATE 


Processing of the ALLOCATE verb by PS.CONV 
includes: 


e Requesting that RM allocate a resource 
control block (RCB). 


e Requesting that RM allocate a session for 
the conversation. 


e Creating an Attach FMH-5. 


The order of performing the last two items 
depends on the supplied RETURN_CONTROL param- 
eter of the ALLOCATE verb, as described 
below. 


A conversation resource is represented by a 
resource control block (RCB--see "PS.CONV 
Data Base Structure" on page 5.1-1). PS.CONV 
requests the creation of an RCB by sending an 
ALLOCATE_RCB record to the resources manager 
(RM) and waiting for an RCB_ALLOCATED record 
in reply. If RETURN_CONTROL( IMMEDIATE) is 
specified, the ALLOCATE_RCB (page A-15) 
record is a ‘composite request for the cre- 
ation of an RCB and the allocation of a 
first-speaker session. This situation is 
indicated to RM by setting ALLO- 
CATE_RCB.IMMEDIATE_SESSION = YES. 


After the RCB has’ been created, PS.CONV 
requests the resources manager to allocate a 
session for use by the conversation (if a 
session has not already been allocated as a 
result of IMMEDIATE_SESSION = YES). PS.CONV 
does this by sending a GET_SESSION record to 
RM and waiting for a SESSION_ALLOCATED record 
in reply. 


The type of end-user’ verification is 
requested in the ALLOCATE as NONE; SAME, or 
PGM. See SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2 for a more com- 
plete description of the security parameter 
relating to end-user verification. 


PS.CONV creates an Attach FMH-5 based on the 
parameter settings in the ALLOCATE verb and 
in the RCB. The Attach is stored in the MU 
buffer, to be sent later. When processing an 
ALLOCATE verb, the Attach is created after 
assignment of the session; thus, any security 
downgrades that are required will have been 
completed prior to building the Attach in PS. 


POST ON RECEIPT 


The POST_ON_RECEIPT verb establishes the 
posting conditions for the conversation. The 
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post conditions (FILL = BUFFER or LL» and 
LENGTH) are retained in the RCB associated 
with the conversation. The posting status 
(reset, pending post, or posted) of a conver- 
sation is maintained by FSM_POST. Whenever 
PS.CONV receives data, end-of-chain type 
(e.g.» SEND, CONFIRM), or both from the 
half-session, the posting conditions are 
checked, and the state of FSM_POST is updated 
if necessary. If POST_ON_RECEIPT has been 
issued, the state of FSM POST may be checked 


by calling TEST_PROC on page 5.1-26. This 


procedure is used by the WAIT verb to deter- 
mine whether the post conditions have been 
satisfied for any of several conversations. 


REQUEST TO SEND 


When the transaction program issues a 
REQUEST_TO_SEND verb, PS.CONV checks the con- 
versation state to see if the verb can be 
validly issued, and checks that the conversa- 
tion is still active. If so, PS.CONV sends a 
REQUEST_TO_SEND record to the appropriate 
half-session process and then waits for a 
RSP_TO_REQUEST_TO_SEND record from the 
half-session. By waiting for a response from 
the half-session before returning to the 
transaction program, PS.CONV prevents the 
transaction program from flooding the network 
with expedited-flow FMD RUs. 


On receipt of a REQUEST_TO_SEND record from a 
half-session (request for send control 
initialted by partner transaction program), 
PS.CONV sets RCB.RQ_TO_ SEND RCVD to YES, and 
notifies the transaction program at the ear- 
liest opportunity. 


SEND ERROR 


Processing of the SEND_ERROR verb by PS.CONV 
includes: 


e If the TP issuing the verb is in receive 
state: 


—- Sending a SEND_ERROR record to the 
half-session. This causes a 
-RSP(0846) to be sent to the partner 
LU. 

—- Waiting until an end-of-chain type is 
received from the partner LU. The 
half-session purges all data until 
the end-of-chain type is received. 


e¢ If the TP issuing the verb is in send 
state: 


- Creating an FMH-7 with the sense data 
based on the SEND_ERROR type and the 
current state of the conversation. A 
-RSP(0846) is not sent when the con- 
versation is in send state as done 
with the conversation when it is in 
receive state. 

- Creating an Error Log GDS variable 
(see SNA Formats for format), if log 
data is present. 
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If both sides of a conversation § issue 
SEND_ERROR, the side that was in receive 
state always wins the SEND_ERROR race and 
obtains send control of the conversation. 
Figure 5.1-6 on page 5.1-8 shows a flow dia- 
gram for a simple SEND_ERROR race. 


Figure 5.1-7 on page 5.1-9 shows a SEND_ERROR 
race with deallocation. In this case, nei- 
ther error gets reported to the other side. 
This problem could be avoided by following 
the SEND_ERROR with a PREPARE_TO_RECEIVE, as 
shown in the previous figure. 


On receipt of a RECEIVE_ERROR record from the 
half-session (as a result of the partner LU 
sending a -RSP[0846]), PS.CONV sends an 
end-of-chain type to the half-session, if it 
has not already done so. It then receives 
the expected FMH-7 and notifies the trans- 
action program, at the earliest opportunity, 
with a return code based on the FMH-7 sense 
data. If it receives an Error Log GDS vari- 
able appended to the FMH-7, the LU logs the 
data without passing it on to the transaction 
program. 


TP PS .CONV HS HS PS.CONV TP 


Figure 5.1-6. 
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SEND_ERROR Race 
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C | TP PS .CONV HS HS PS .CONV TP 


Figure 5.1-7. 
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SEND_ERROR Race with Deallocation 


PROTOCOL ERRORS 


PS.CONV contains a number of optional receive 
checks to determine if the partner LU has 
violated SNA-defined protocols. Examples of 
protocol violations checked by PS.CONV 
include: 


e Sending data when in receive state 

e Invalidly truncating a logical record 
(see "Tracking Logical Record Length" on 
page 5.1-6 ) 

e Sending an incorrectly formatted FMH-7 


When PS.CONV detects a protocol error, it 
requests that RM deactivate the session and 
sets FSM _ERROR_OR_FAILURE (see page 5.1-67) 
to indicate that a conversation failure (pro- 
tocol error) occurred. PS.CONV notifies the 
transaction program of the conversation fail- 
ure by returning a RESOURCE_FAILURE return 
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code on the next verb’ that allows a 
RESOURCE_FAILURE return code. 


CONVERSATION FAILURES 


PS.CONV is notified of a conversation failure 
by the CONVERSATION_FAILURE record, sent by 
RM. The conversation failure may result from 
either session outage or a protocol vio- 
lation. 


On receipt of a CONVERSATION_FAILURE (see 
page A-21) record, PS .CONV sets 
FSM_ERROR_OR_FAILURE to indicate either 
CONV_FAILURE_SON : or 
CONV_FAILURE_PROTOCOL_ERROR. PS.CONV noti- 
fies the transaction program of the conversa- 
tion failure by returning a RESOURCE_FAILURE 
return code on the next verb that allows a 
RESOURCE_FAILURE return code. 
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HIGH-LEVEL PROCEDURES 
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PS_CONV 


FUNCTION: 


INPUT : 


OUTPUT : 


Referenced pr 
ALLO 
CONF 
CONF 
DEAL 
FLUS 
GET_ 


This procedure 


receives conversation verbs 


issued by the TP or by other PS 


components, and calls the appropriate procedures to process them. 


Transaction program verb and parameters 


Refer to the procedures 
outputs. 


ocedures, FSMs, and data structures: 
CATE_PROC 

IRM_PROC 

IRMED_PROC 

LOCATE_PROC 

H_PROC 

ATTRIBUTES_PROC 


POST_ON_RECEIPT_PROC 


PREP 
RECE 
RECE 
REQU 


ARE_TO_RECEIVE_PROC 
IVE_AND_WAIT_PROC 
IVE_IMMEDIATE_PROC 
EST_TO_SEND_PROC 


SEND_DATA_PROC 
SEND_ERROR_PROC 
TEST_PROC 


Select based 
When ALLOC 


on the transaction program verb: 
ATE 


that are called from this procedure for the specific 


page 5.1-11 
page 5.1-12 
page 5.1-14¢ 
page 5.1-15 
page 5.1-16 
page 5.1-17 
page 5.1-17 
page 5.1-18 
page 5.1-19 
page 5.1-21 
page 5.1-23 
page 5.1-24¢ 
page 5.1-25 
page 5.1-26 


Call ALLOCATE_PROC( ALLOCATE verb parameters) (page 5.1-11). 


When CONFI 


RM 


Call CONFIRM_PROC( CONFIRM verb parameters) (page 5.1-12). 


When CONFI 


RMED 


Call CONFIRMED_PROC(CONFIRMED verb parameters) (page 5.1-14). 


When DEALL 


OCATE 


Call DEALLOCATE_PROC(DEALLOCATE verb parameters) (page 5.1-15). 


When FLUSH 


Call FLUSH_PROC( FLUSH verb parameters) (page 5.1-16). 


When GET_A 


TTRIBUTES 


Call GET_ATTRIBUTES_PROC(GET_ATTRIBUTES verb parameters) (page 5.1-17). 


When POST_ 


Call PO 
When PREPA 


ON_RECEIPT 


ST_ON_RECEIPT_PROC( POST_ON_RECEIPT verb parameters) (page 5.1-17). 


RE_TO_RECEIVE 


Call PREPARE_TO_RECEIVE_PROC(PREPARE_TO_RECEIVE verb parameters) (page 5.1-18). 


When RECEI 


VE_AND_WAIT 


Call RECEIVE_AND_WAIT_PROC(RECEIVE_AND_WAIT verb parameters) (page 5.1-19). 


When RECEI 


VE_IMMEDIATE 


Call RECEIVE_IMMEDIATE_PROC( RECEIVE_IMMEDIATE verb parameters) (page 5.1-21). 


When REQUE 


ST_TO_SEND 


Call REQUEST_TO_SEND_PROC( REQUEST_TO_SEND verb parameters) (page 5.1-23). 
When SEND_DATA 
Call SEND_DATA_PROC(SEND_DATA verb parameters) (page 5.1-24). 
When SEND_ERROR 
Call SEND_ERROR_PROC(SEND_ERROR verb parameters) (page 5.1-25). 


When TEST 


Call TEST_PROC(TEST verb parameters) (page 5.1-26). 
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ALLOCATE_PROC 


ALLOCATE_PROC 


This procedure handles allocation of new resources to the transaction program. 


If the ALLOCATE parameters are valid, this procedure requests that RM create a 
new resource control block (RCB). If the supplied RETURN_CONTROL parameter 
specifies IMMEDIATE, PS at this time also requests RM to acquire a session for 
use by the conversation resource. If the RETURN_CONTROL is set to 
WHEN_SESSION_ALLOCATED, PS sends a_ separate GET_SESSION request to RM ata 
later time. 


INPUT: ALLOCATE verb with parameters; RCB_ALLOCATED record received from RM 


OUTPUT: The ALLOCATE_RCB' record is initialized and sent to RM and the RCB_ALLOCATED 
record (from RM) is destroyed. If an error is found in the ALLOCATE, the 
return code is updated. 


If the ALLOCATE specifies SECURITY(SAME), but the original conversation was 
not initialized with security, then the security is downgraded to NONE on the 


C- ALLOCATE_RCB before sending the request to the resources manager. 
Referenced procedures, FSMs, and data structures: 

PS page 5.0-8 
RM page 3-19 
RCB_ALLOCATED_PROC page 5.1-48 
WAIT_FOR_RM_REPLY page 5.1-62 
ALLOCATE_RCB page A-15 
MODE page A-3 
RCB_ALLOCATED page A-21 


Check ALLOCATE parameters for validity (see ALLOCATE verb in 


% ea a ak rs a Ras Ss: ——— —_ — ———— — 
C : If ALLOCATE parameters are valid then 
- If MODE control block exists then 
Create and initialize ALLOCATE_RCB request record with the 
parameters of the ALLOCATE. 
SEND ALLOCATE_RCB request to RM. 
Call WAIT_ FOR_ RM_REPLY to receive RCB_ALLOCATED from RM (page 5.1-62). 
Call RCB_ALLOCATED_PROC(RCB_ALLOCATED, ALLOCATE )(page 5.1-48). 
Else 
Set the RETURN_CODE of the ALLOCATE verb to PARAMETER_ERROR. 
Else 
Set the RETURN_CODE of the ALLOCATE verb to PROGRAM_PARAMETER_CHECK. 
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CONFIRM_PROC 


FUNCTION: 


INPUT: 


OUTPUT: 


This procedure handles the CONFIRM verb processing. 


If it is appropriate for the transaction program to issue a CONFIRM for the 
specified conversation (i.e., the SYNC_LEVEL of the conversation for which the 
CONFIRM was issued is CONFIRM or SYNCPT and any data issued by the transaction 
program is on a logical record boundary), this procedure retrieves any records 
from HS. and RM. Appropriate action is taken depending upon which, if any> 
record was received (as reflected by the state of FSM_ERROR_OR_FAILURE). 


CONFIRM verb parameters 


An RQ_TO_SEND_RCVD indication could be passed up to the TP at this time if the 
RCB.RQ_TO_SEND_RCVD field has been set to show receipt of a RQ_TO_SEND. The 
RCB.RQ_TO_SEND_RCVD field is reset to NO. The return code of the CONFIRM verb 
is updated. See Notes for additional outputs. 


If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the CONFIRM to RESOURCE_FAILURE. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA record with 
the MU.PS TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in 
the RCB send buffer was purged when the RECEIVE_ERROR record was received. ) 
If an MU is not present, one is_ created and initialized prior to sending to 
HS. PS then waits for the expected FMH-7 error message to arrive. The 
RETURN_CODE parameter of the CONFIRM is set based on the sense data carried in 
the FMH-7. 


If there are no error or failure conditions, COMPLETE_CONFIRM_PROC is called 
to complete the processing of the CONFIRM. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
COMPLETE_CONFIRM_PROC page 5.1-28 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
DEQUEUE_FMH7_PROC page 5.1-34¢ 
RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If RCB.SYNC_LEVEL is NONE or the send data is not at a logical record boundary then 


If RCB.SYNC_ 


LEVEL is NONE then 


Set the RETURN_CODE of the CONFIRM verb to PROGRAM_PARAMETER_CHECK. 
Else (not on logical record boundary ) 
Set the RETURN_CODE of the CONFIRM verb to PROGRAM_STATE_CHECK. 


Else 


If executing FSM_CONVERSATION(S, CONFIRM, RCB) (page 5.1-65) would cause 
a state-check (>) condition then 
Set the RETURN_CODE of the CONFIRM verb to PROGRAM_STATE_CHECK. 


Else 


Call RECEIVE_RM_OR_HS TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 


Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR (see Note 1) 
Set the RETURN_CODE of the CONFIRM verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When CONV_FAILURE_SON (see Note 1) 
Set the RETURN_CODE of the CONFIRM verb to RESOURCE_FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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CONFIRM_PROC 


i When RCVD_ERROR (see Note 2) 
‘ If a send MU buffer does not exist then 
/ Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU record to HS. 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 
Set the RETURN_CODE of the CONFIRM verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the CONFIRM verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else 
Call DEQUEUE_FMH7_PROC(CONFIRM verb parameters, RCB) (page 5.1-34). 
When NO_REQUESTS (see Note 3) 
Call COMPLETE_CONFIRM_PROC(CONFIRM verb parameters, RCB) (page 5.1-28). 
Set the REQUEST_TO_SEND_RECEIVED of the CONFIRM verb to RCB.RQ_TO_SEND_RCVD. 
Set RCB.REQUEST_TO_SEND_RECEIVED to NO. 
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CONFIRMED_PROC 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 


1. 


This procedure handles CONFIRMED verb processing. 


PS first retrieves any records from HS and RM. Appropriate action is taken 
depending upon which, if any» record was received. 


CONFIRMED verb parameters 


The return code of the CONFIRMED verb is set. The states of FSM_CONVERSATION 
and FSM_ERROR_OR_FAILURE may change. See Notes for additional outputs. 


If a CONVERSATION_FAILURE record has been received from the resources manager > 
PS returns to the transaction program without sending any data to HS. Since 
CONFIRMED verb does not support a RESOURCE_FAILURE return code, the conversa- 
tion failure cannot be reported to the transaction program at this time. PS 
remembers the failure (via FSM_ERROR_OR_FAILURE) and reports it to the trans- 
action program at a later time (i.e., when the transaction program issues a 
verb that supports a RESOURCE_FAILURE return code). 


If a CONVERSATION_FAILURE record has not been received, PS sends a CONFIRMED 
record to HS. 


Referenced procedures, FSMs» and data structures: 


PS _PROTOCOL_ERROR page 5.0-20 
SEND_CONFIRMED_PROC page 5.1-53 
RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_CONVERSATION | page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 

Set the RETURN_CODE of the CONFIRMED verb to PROGRAM_STATE_CHECK. 


Else 


Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When NO_REQUESTS (see Note 2) 
Call SEND_CONFIRMED_PROC(RCB) (page 5.1-53). 
When RCVD_ERROR 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'10010000') (page 5.0-20). 
When CONV_FAILURE_PROTOCOL_ERROR or CONV_FAILURE_SON (see Note 1) 
Do nothing. | 


Call FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-65). 
Set the RETURN_CODE of the CONFIRMED verb to OK. 
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- DEALLOCATE_PROC 
S 
FUNCTION: This procedure handles the deallocation of resources. 
If the resource specified in the DEALLOCATE is a valid resource and the con- 
versation is in a pertinent state, PS calls the appropriate deallocation pro- 


cedure to continue processing the DEALLOCATE. 


INPUT: DEALLOCATE verb parameters 


OUTPUT : The return code of the DEALLOCATE is set here or in one of the called proce- 
dures, and FSM_CONVERSATION may change states. Also, the pertinent deallo- 
cation procedure is called. When appropriate, PS sends DEALLOCATE_RCB to RM. 


Referenced procedures, FSMs> and data structures: 


DEALLOCATE_ABEND_PROC page 5.1-31 

DEALLOCATE_CONFIRM_PROC page 5.1-32 

DEALLOCATE_FLUSH_PROC page 5.1-33 

a END_CONVERSATION_PROC page 5.1-34 

C ; FSM_CONVERSATION page 5.1-65 
engl RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
Select based on the following conditions: 
When the TYPE parameter of DEALLOCATE is FLUSH, or the TYPE parameter is SYNC_LEVEL 
and RCB.SYNC_LEVEL is NONE 
If executing FSM_CONVERSATION(S, DEALLOCATE_FLUSH, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 
Call DEALLOCATE_FLUSH_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-33). 
When the TYPE parameter is CONFIRM 


ay If executing FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-65) would 
} cause a state-check (>) condition then 
‘ Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 


If RCB.SYNC_LEVEL is CONFIRM or SYNCPT then 
Call DEALLOCATE_CONFIRM_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-32). 
Else 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_PARAMETER_CHECK. 
When the TYPE parameter is SYNC_LEVEL and RCB.SYNC_LEVEL is CONFIRM 
If executing FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 
* Call DEALLOCATE_CONFIRM_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-32). 
C When the TYPE parameter 1s SYNC_LEVEL and RCB.SYNC_LEVEL is SYNCPT 
If executing FSM_CONVERSATION(S, DEALLOCATE_DEFER, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 
If the data sent by TP is on a logical record boundary then 
Call FSM_CONVERSATION(S, DEALLOCATE_DEFER, RCB) (page 5.1-65). 
Set the RETURN_CODE of the DEALLOCATE verb to OK. 
Else 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
When the TYPE parameter is ABEND_PROG, ABEND_SVC, or ABEND_TIMER 
If executing FSM_CONVERSATION(S, DEALLOCATE_ABEND, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else i 
Call DEALLOCATE_ABEND_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-31). 
When the TYPE parameter is LOCAL 
If executing FSM_CONVERSATION(S, DEALLOCATE_LOCAL, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 


i Else 
S Set the RETURN_CODE of the DEALLOCATE verb to OK. 


Call FSM_CONVERSATION(S, DEALLOCATE_LOCAL, RCB) (page 5.1-65). 
Call END_CONVERSATION_PROC(RCB) (page 5.1-34). 
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FLUSH_PROC 


FUNCTION: 


INPUT : 


OUTPUT: 


This procedure handles the FLUSH verb processing. 


The procedure first receives records from RM and HS. Appropriate action is 
taken depending upon the type of the received record as indicated by the 
FSM_CONVERSATION and FSM_ERROR_OR_FAILURE states. 


FLUSH verb parameters, records from RM and HS 


The send MU.PS_TO_HS.TYPE field is set according to the state of 
FSM.CONVERSATION, and the return code on the FLUSH verb is set. If a sending 
MU is present and contains data, the MU will be sent to HS. See Notes for 
additional outputs. 


If PS has received a RECEIVE_ERROR from HS, or no error records’ have been 
received, PS sends any data remaining in the RCB send buffer to HS with the 


MU.PS TO_HS.TYPE field of the SEND_DATA set to FLUSH, PREPARE_TO_RCV_FLUSH, or 


DEALLOCATE_FLUSH, depending on the state of the conversation. (If a 
RECEIVE ERROR was received, any data in PS's send buffer has’ already been 
purged. ) 


If FSM_ERROR_OR_FAILURE indicates that a conversation failure has occurred, PS 
returns to the transaction program without sending any data to HS. Since 
FLUSH does not support RESOURCE_FAILURE return code, the error cannot be 
reported to the transaction program at this time. PS remembers the error (via 
FSM_ERROR_OR_FAILURE) and reports it to the transaction program at a later 
time (1i1.e., when PS receives a record from the transaction program that sup- 
ports a RESOURCE_FAILURE return code). 


Referenced procedures, FSMs, and data structures: 
_ HS 


7 page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
END_CONVERSATION_PROC page 5.1-34 
RECEIVE RM_OR_HS_TO_PS_RECORDS | page 5.1-51 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 


Find RCB for the conversation identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, FLUSH, RCB) (page 5.1-65) would 
cause a state-check (>) condition then 

Set the RETURN_CODE of the FLUSH verb to PROGRAM_STATE_CHECK. 


Else 


Call RECEIVE _RM_OR_HS_TO PS _RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
If the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is RCVD_ERROR 
or NO_REQUESTS then (see Note 1) 
Select based on the state of FSM_CONVERSATION (page 5.1-65): 
When SEND_STATE 


If 


a send MU buffer exists and the MU contains data then 
Send the MU record to HS. 


When PREP_TO_RCV_DEFER 


If 


a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Set MU.PS_TO_HS.TYPE to PREPARE TO_RCV_FLUSH and send the MU record to HS. 
When DEALL_DEFER 


If 


a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Set MU.PS_TO_HS.TYPE to DEALLOCATE_FLUSH and send the MU record to HS. 
If the state of FSM_CONVERSATION is DEALL_DEFER then 
Call END_CONVERSATION_PROC(RCB) (page 5.1-34). 
Call FSM_CONVERSATION(S, FLUSH, RCB) (page 5.1-65). 
Set the RETURN_CODE of the FLUSH verb to OK. 


SNA LU 6.2 Reference: Peer Protocols 


GET_ATTRIBUTES_PROC 


GET_ATTRIBUTES_PROC 


FUNCTION: This procedure handles requests for information about a conversation. 


Information about the conversation resource is retrieved from the pertinent 
control blocks, and placed in the returned parameters of the GET_ATTRIBUTES 
verb. 


INPUT: GET_ATTRIBUTES verb parameters 


OUTPUT :. GET_ATTRIBUTES verb returned parameters containing information about the con- 
versation 


= Referenced procedures, FSMs, and data structures: 
: FSM_CONVERSATION page 5.1-65 
C PARTNER_LU page A-2 
RCB | page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
Set the returned parameters of the GET_ATTIBUTES verb as follows: 
PARTNER_FULLY_QUALIFIED_LU_NAME to PARTNER_LU.FULLY QUALIFIED _LU_NAME, 
PARTNER_LU_NAME to RCB.LU_NAME, 
MODE_NAME to RCB.MODE_NAME ,; 
SYNC_LEVEL to RCB.SYNC_LEVEL, 
Set the RETURN_CODE of the GET_ATTRIBUTES verb to OK. 
Call FSM_CONVERSATION(S, GET_ATTRIBUTES, RCB) (page 5.1-65). 


POST_ON_RECEIPT _PROC 


FUNCTION: This procedure performs the processing of the POST_ON_RECEIPT verb. 


This procedure updates FSM_CONVERSATION and FSM_POST, saves the post condi- 
tions in the RCB, and retrieves any records originated in RM and HS. The data 
just received from RM or HS may cause the resource to be posted. 


() 


INPUT: POST_ON_RECEIPT verb parameters 


OUTPUT: The return code of the verb is updated. If the verb is issued in a valid 
state, then the state of FSM_POST is changed. FSM_CONVERSATION is called but 
does not change states. Also,» POST_CONDITIONS. FILL and 
POST_CONDITIONS.MAX_LENGTH in the RCB are updated to the posting conditions. 


Referenced procedures, FSMs, and data structures: 


RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_CONVERSATION page 5.1-65 
FSM_POST page 5.1-68 
RCB page A-6 
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If executing FSM_CONVERSATION(S, POST_ON_RECEIPT, RCB) (page 5.1-65). 
would cause a state-check (>) condition then 
Set the RETURN_CODE of the POST_ON_RECEIPT verb to PROGRAM_STATE_CHECK. 
Else 
Call FSM_CONVERSATION(S, POST_ON_RECEIPT, RCB) (page 5.1-65). 
Call FSM_POST (page 5.1-68) and pass it a POST_ON_RECEIPT signal. 
Set RCB.POST_CONDITIONS.FILL to the FILL parameters of the POST_ON_RECEIPT verb. 
Set RCB.POST_CONDITIONS.MAX LENGTH to the LENGTH parameters of the POST_ON_RECEIPT verb. 
Call RECEIVE RM_OR_HS_TO_PS_RECORDS( empty SUSPEND_LIST) (page 5.1-51). 
Set the RETURN_CODE of the POST_ON_RECEIPT verb to OK. 


Find the RCB for the conversation identified in the RESOURCE parameter. | C- 


PREPARE_TO_RECEIVE_PROC 


FUNCTION: This procedure handles the PREPARE_TO_RECEIVE verb. Depending on the TYPE of 
the PREPARE_TO_RECEIVE (FLUSH, CONFIRM or SYNC_ LEVEL) and the SYNC_LEVEL of 
the conversation (NONE, CONFIRM, or SYNCPT), the processing of the PRE- 
PARE_TO_RECEIVE is continued by other procedures. 


. INPUT: PREPARE_TO_RECEIVE verb parameters 


OUTPUT : If the PREPARE_TO_RECEIVE specifies TYPE = SYNC_LEVEL and the SYNC_LEVEL of 
the conversation is SYNCPT, the RETURN_CODE is set to OK and FSM_CONVERSATION 
is updated to indicate that completion of the PREPARE_TO_RECEIVE processing is 
deferred until a FLUSH, CONFIRM, or SYNCPT verb is’ issued. Otherwise, proc- 
essing is continued by other procedures. 


Referenced procedures, FSMs» and data structures: | ( 
PREPARE_TO_RECEIVE_CONFIRM_PROC page 5.1-41 Se" 
PREPARE_TO_RECEIVE_FLUSH_PROC page 5.1-42 
FSM_CONVERSATION page 5.1-65 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If the data sent by TP is not on a logical record boundary then 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_STATE_CHECK. 
Else 
Select based on the following conditions: 
When the TYPE parameter of the PREPARE_TO_RECEIVE verb is FLUSH; or the TYPE is 
SYNC_LEVEL and the conversation sync level is NONE (~~ 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE. FLUSH, RCB) (page 5.1-65). \ 
would cause a state-check (>) condition then 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_STATE_CHECK. 
Else 
Call PREPARE_TO_RECEIVE_FLUSH_PROC(PREPARE_TO_RECEIVE verb parameters, RCB) 
(page 5.1-42). 
When the TYPE parameter of the PREPARE_TO_RECEIVE verb is CONFIRM 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE CONFIRM, RCB) (page 5.1-65). 
would cause a state-check (>) condition then 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_STATE_CHECK. 
Else 
If sync level of the conversation is CONFIRM or SYNCPT then 
Call PREPARE_TO_RECEIVE_CONFIRM_PROC( PREPARE_TO_RECEIVE verb parameters, RCB) 
(page 5.1-41). 
Else 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_PARAMETER_CHECK. 
When the TYPE parameter of the PREPARE_TO_RECEIVE verb is SYNC_LEVEL and the conversation 
sync level is CONFIRM 
If executing FSM_CONVERSATION(S, PREPARE_TO_ RECEIVE _CONFIRM, RCB) (page 5.1-65). 
would cause a state-check (>) condition then _ 
Set the RETURN _CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_STATE_CHECK. C- 
Else 
Call PREPARE_TO_RECEIVE_CONFIRM_PROC( PREPARE_TO_RECEIVE verb parameters, RCB) al 
(page 5.1-41). 
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ae When the TYPE parameter of the PREPARE_TO_RECEIVE verb is SYNC_LEVEL and the conversation 
7 sync level is SYNCPT | 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_DEFER, RCB) (page 5.1-65). 
would cause a state-check (>) condition then 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to PROGRAM_STATE_CHECK. 
Else 
Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_DEFER, RCB) (page 5.1-65). 
Set RCB.LOCKS to the LOCKS parameter in the PREPARE_TO_RECEIVE verb. 
Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb parameter to OK. 


RECEIVE _AND_WAIT_PROC 


FUNCTION: This procedure handles the RECEIVE_AND_WAIT verb. 


If the conversation is in an appropriate state (1.e., RECEIVE _AND_WAIT can be 

| issued when the conversation 1s in the send or receive, state), processing of 

C the record continues. PS first receives any records from RM and HS. Appro- 

es priate action is taken depending upon which, if any» record was received (as 
reflected by the state of FSM_ERROR_OR_FAILURE ). 


INPUT: RECEIVE_AND_WAIT verb parameters 


OUTPUT : The DATA field is cleared before receiving data from HS. RCB.RQ_TO_SEND_RCVD 
is updated. If a RQ_TO_SEND has been received, an indication will be passed 
up to the TP at this time, and the field in the RCB is updated. The state of 
FSM_CONVERSATION may change. See below for additional outputs. 


If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter to 
E RESOURCE_FAILURE. The setting of RESOURCE_FAILURE is done after all data cur- 
« i rently buffered 1s passed up to the transaction program. 


If a RECEIVE_ERROR has been received from. HS, PS sends a SEND_DATA record with 
the MU.PS_TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in 
the RCB send buffer was purged when the RECEIVE_ERROR record was received. ) 
PS then waits for the expected FMH-7 error message to arrive. The RETURN_CODE 
parameter of the RECEIVE _AND_WAIT is set based on the sense data carried in 
the FMH-7. 


If the conversation is in the SEND state, PS sends the MU record, containing 
all saved data from the transaction program, with the MU.PS_TO_HS.TYPE field 
ae set to PREPARE_TO_RCV_FLUSH to HS. Regardless of the state of the conversa- 
F tion, PS initializes the post conditions, waits for information to arrive to 
cause the conversation to become posted, and returns to the transaction pro- 

gram with the received information. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 

CREATE_AND_INIT_LIMITED_MU page 5.1-30 
DEQUEUVE_FMH7_PROC , | page 5.1-34 
RECEIVE _AND_TEST_POSTING page 5.1~50 
RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1~51 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A~-6 
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Find the RCB for the conversation identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S,RECEIVE_AND_WAIT, RCB) would 
cause a state-check (>) condition then 
Set the RETURN_CODE of the RECEIVE_AND_WAIT verb to PROGRAM_STATE_CHECK. 
Else 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
If the state of FSM_ERROR_OR_FAILURE is RCVD_ERROR then (see Note 2) 
If the state of FSM_CONVERSATION is SEND_STATE then (see Note 3) 
If a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU record to HS. 
If the FMH7 is not in the RCB.HS_TO_PS_BUFFER_LIST then 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 
If the state of FSM_ERROR_OR_FAILURE is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then (see Note 1) 
If the state of FSM_ERROR_OR_FAILURE is CONV_FAILURE_SON then 
Set the RETURN_CODE of the RECEIVE_AND_WAIT verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the RECEIVE_AND_WAIT verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else 
Call DEQUEUE_FMH7_PROC(RECEIVE_AND_WAIT verb parameters, RCB) (page 5.1-34). 
Else : . 
Call FSM_CONVERSATION(S, RECEIVE_AND_WAIT, RCB) (page 5.1-65). 
Initialize the DATA parameter of the RECEIVE_AND_WAIT verb to null. 
Call RECEIVE._AND_TEST_POSTING(RCB, RECEIVE _AND_WAIT verb parameters) (page 5.1-50). 
Set REQUEST_TO_SEND_RECEIVED of the RECEIVE_AND_WAIT verb to RCB.RQ_TO_SEND_RCVD. 
Set RCB.RQ_TO_SEND_RCVD to NO. 
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FUNCTION: This procedure performs the processing of the RECEIVE_IMMEDIATE verb. It 
receives any information available from the specified conversation, but does 
not wait for information to arrive. 


The procedure first receives any records from the RM_TO_PS and HS_TO_PS 
queues. Appropriate action is taken depending upon which, if any, record was 
received (as reflected by the state of FSM_ERROR_OR_FAILURE ). 


INPUT: RECEIVE_IMMEDIATE verb parameters 


OUTPUT: The RCB.POST_CONDITIONS.MAX_LENGTH and FILL are updated to reflect the values 
on the verb. The DATA field of the RECEIVE_IMMEDIATE verb is cleared before 
the data is received from HS. After receive processing is performed, the 
state of FSM_POST is reset and the data is_ returned to the TP. The 


RETURN_CODE and REQUEST_TO_SEND_RECEIVED fields of the RECEIVE_IMMEDIATE 
record are also set to indicate the result of the verb. See below for addi- 
tional output. 


( ; If a CONVERSATION_FAILURE has been received from the resources manager», PS 
— returns to the transaction program after setting the RETURN_CODE field in the 
RECEIVE_IMMEDIATE to RESOURCE_FAILURE. 


If a RECEIVE_ERROR has been received from HS» PS waits for the expected FMH-7 
error message to arrive. The RETURN_CODE field in the RECEIVE_IMMEDIATE is 
set based on the sense data carried in the FMH-7. 


If no error or failure condition has occurred, PS_~ calls PER- 
FORM_RECEIVE_ PROCESSING (page 5.1-40), which checks to see if any information 
has arrived on the specified conversation and passes the received information 
(if any) to the transaction program. 


C ) Referenced procedures, FSMs, and data structures: 

DEQUEUE_FMH7_PROC page 5.1-34¢ 
PERFORM_RECEIVE_PROCESSING page 5.1-40 
RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
FSM_POST page 5.1-68 
RCB page A-6 
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RECEIVE_IMMEDIATE_PROC 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) would 


cause a state-check (>) condition then 


SET the RETURN_CODE of the RECEIVE_IMMEDIATE verb to PROGRAM_STATE_CHECK. 


Else 


Call RECEIVE_RM_OR_HS_TO_PS_RECORDS( empty SUSPEND_LIST) (page 5.1-51). 
If the state of FSM_ERROR_OR_FAILURE is RCVD_ERROR then 
If the FMH7 is not in the RCB.HS_TO_PS BUFFER_LIST then 
Call RECEIVE_RM_OR_HS TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 


If the state of FSM_ERROR_OR_FAILURE 
CONV_FAILURE_PROTOCOL_ERROR then 


is CONV_FAILURE_SON or 


If the state of FSM_ERROR_OR_FAILURE is CONV_FAILURE_SON then 
Set the RETURN_CODE of the RECEIVE_IMMEDIATE verb to RESOURCE_FAILURE_RETRY. 


Else 


Set the RETURN_CODE of the RECEIVE_IMMEDIATE verb to RESOURCE_FAILURE_NO_RETRY. 


Call FSM_CONVERSATION(R, RESOURCE_ 


Else 


FAILURE_RC» RCB) (page 5.1-65). 


Call DEQUEUVE_FMH7_PROC(RECEIVE_IMMEDIATE verb parameters, RCB) (page 5.1-34). 


Else (see Notes 1 and 3) 


Call FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) (page 5.1-65). 
Set RCB.POST_CONDITIONS.MAX_LENGTH to the RECEIVE_IMMEDIATE verb MAX_LENGTH value. 
Set RCB.POST_CONDITIONS.FILL to the RECEIVE_IMMEDIATE verb FILL value. 


Initialize the DATA parameter of the 
Call PERFORM_RECEIVE_PROCESSING(RCB, 
Call FSM_POST (page 5.1-68) and pass 
Set MAX_LENGTH of the RECEIVE _IMMEDIATE 


RECEIVE_IMMEDIATE verb to null. 

RECEIVE_IMMEDIATE verb parameters) (page 5.1-40). 
it a RECEIVE_IMMEDIATE signal. 

verb to the length of data returned. 


Set REQUEST_TO_SEND_RECEIVED of the RECEIVE_IMMEDIATE verb to RCB.RQ_TO_SEND_RCVD. 


Set RCB.RQ_TO_SEND_RCVD to NO. 
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FUNCTION: This procedure handles REQUEST_TO_SEND verb processing. 


If the conversation is in the RECEIVE state, PS completes the processing of 
the REQUEST_TO_SEND record, as described below. 


INPUT: REQUEST_TO_SEND verb parameters 


OUTPUT : The REQUEST_TO_SEND return code is updated, and a REQUEST_TO_SEND will be 
sent. See below for additional outputs. 


NOTES: . Since REQUEST_TO_SEND does not support a RESOURCE_FAILURE return code, error 
conditions cannot be relayed to the transaction program at this time. PS 
remembers the error (via FSM_ERROR_OR_FAILURE) and reports it to the trans- 
action program at a later time (1.e., when a verb is issued by the transaction 
program that supports a RESOURCE_FAILURE return code). 


. A REQUEST_TO_SEND record is not sent to HS if the partner transaction program 
a has already issued a DEALLOCATE for the specified conversation. 


e » A REQUEST_TO_SEND record is not sent to HS if the partner transaction program 
has already issued a PREPARE_TO_RECEIVE for the specified conversation. 


If no records have been received from HS, or records have been received but do 
not indicate DEALLOCATE- or PREPARE_TO_RCV; this procedure = sends 
REQUEST_TO_SEND to HS and waits for the expected RSP_TO_REQUEST_TO_SEND before 
returning to the transaction program. 


Referenced procedures, FSMs, and data structures: 


RECEIVE _RM_OR_HS_TO_PS_ RECORDS page 5.1-51 

SEND_REQUEST_TO_SEND_PROC page 5.1-58 

—s WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC | page 5.1-63 

C FSM_CONVERSATION page 5.1-65 

aa FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) would cause 
a state-check (>) condition then 
Set the RETURN CODE of the REQUEST_TO SEND verb to PROGRAM_STATE_CHECK. 
Else 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 


If the state of FSM_ERROR_OR_FAILURE is NO_REQUESTS or RCVD_ERROR (see Note 1) then 


( Select based on the received end-of-chain type for the conversation: 
; When DEALLOCATE_FLUSH or DEALLOCATE_CONFIRM (see Note 2) 
Ser Do nothing. 
When PREPARE_TO_RCV_FLUSH or PREPARE_TO_RCV_CONFIRM (see Note 3) 
Do nothing. 


Otherwise (see Note 4) . 
Call SEND _REQUEST_TO SEND _PROC(RCB) (page 5.1-58). 
Call WAIT_FOR_RSP_TO_RQ TO SEND PROC(RCB) (page 5.1-63). 
Set the RETURN_CODE of the REQUEST_TO_SEND verb to OK. 
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FUNCTION: This procedure handles the receipt of data from the transaction program. 


If the resource specified in the SEND_DATA is valid and the conversation is in 
the SEND state, processing of the record continues. PS first retrieves any 
records from RM and HS. Appropriate action is taken depending upon which, if 
any, record was received. 


INPUT : SEND_DATA verb parameters and a possible RQ_TO_SEND may have been received on 
this conversation. 


OUTPUT: The RETURN_CODE of the SEND_DATA verb is set. The states of FSM_CONVERSATION 
and FSM_ERROR_OR_FAILURE may changed. If RQ_TO_SEND_RCVD has_ been received; 
an indication is’ stored in the RCB.RQ_TO_SEND_RCVD field. This YES/NO indi- 
cation will be passed up to the TP and then the RCB.RQ_TO_SEND_RCVD field is 
reset to indicate that no RQ_TO_SENDs are outstanding. See Notes for addi- 
tional outputs. 


If a CONVERSATION_FAILURE record has been received from the resources manager > 
PS returns to the transaction program after setting the RETURN_CODE parameter 
of the SEND_DATA to RESOURCE_FAILURE. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA record with 
the MU.PS _TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in 
the RCB send buffer was purged when the RECEIVE _ERROR record was received. ) 
PS then waits for the expected FMH-7 error message to arrive. The RETURN_CODE 
parameter of the SEND_DATA is set based on the sense data carried in the 
FMH-7. 


If no error or failure condition has occurred, PS scans the data in the passed 
SEND_DATA for logical record boundaries. (PS maintains in the RCB a count of 
the number of bytes of data remaining to be sent from the transaction program 
to finish the current logical record.) If there is enough data to send to HS; 
PS sends it. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 

CREATE_AND “INIT_LIMITED_MU page 5.1-30 
DEQUEVUE_FMH7_PROC page 5.1-34 

RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
SEND_DATA_BUFFER_MANAGEMENT page 5.1-54¢ 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 

MU page A-29 

RCB page A-6 ( 


Find the RCB for the conversation identified in the RESOURCE parameter. a 
If executing FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) would cause a 
state-check (>) condition then 
Set the RETURN CODE of the SEND_DATA verb to PROGRAM_STATE_CHECK. 
Else 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
Select based on the state of FSM_ERROR_OR_FAILURE 
When CONV_FAILURE_PROTOCOL_ERROR or CONV_FAILURE_SON (see Note 1) 
If the state of FSM_ERROR_OR_ FAILURE is CONV_FAILURE_SON then 
Set the RETURN _CODE of the SEND DATA verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the SEND_DATA verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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When RCVD_ERROR (see Note 2) 
If a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU record to HS. 
Call RECEIVE _RM_OR_HS TO PS RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 


If the state of FSM _ERROR_OR_FAILURE is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR (see Note 1) then 
If the state of FSM _ERROR_OR_FAILURE is CONV_FAILURE_SON then 
Set the RETURN_CODE of the SEND_DATA verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the SEND _DATA verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R» RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else 
Call DEQUEUE_FMH7_PROC(SEND_DATA verb parameters, RCB) (page 5.1-34). 
When NO_REQUESTS (see Note 3) 
Set the RETURN_CODE of the SEND_DATA verb to OK. 
If MAX_LENGTH of the SEND_DATA verb is greater than 0 then 
Perform the LL processing (see Note 3). 
If LL is not valid (1.e., values X'0000', X'8000', and X'8001' are not valid; 
X'0001' is valid only for PS headers--see SNA Formats) then 
Set the RETURN_CODE of the SEND_DATA verb to PROGRAM_PARAMETER_CHECK. 
Else 
Call SEND_DATA_BUFFER_MANAGEMENT( DATA from SEND DATA verb, RCB) (page 5.1-54). 
Set REQUEST_TO_SEND_RECEIVED of the SEND_DATA verb to RCB.RQ_TO_SEND_RCVD. 
Set RCB.RQ_TO_SEND_RCVD to NO. 


SEND_ERROR_PROC 


FUNCTION: This procedure handles the SEND_ERROR verb processing. 


If the resource specified in the SEND_ERROR is valid and the conversation is 
in an appropriate state, processing of the SEND_ERROR continues. PS first 
retrieves any records from RM and HS. Appropriate action is taken depending 
‘upon which, if any», record was received (as reflected by the state of 
FSM_ERROR_OR_FAILURE ). 


INPUT : SEND_ERROR verb parameters 


OUTPUT: The return code of the SEND_ERROR verb is updated. If the RCB indicates that 
a RQ_TO_SEND_RCVD has’ been received, it will be passed up to the TP at this 
time and the RCB.RQ_TO_SEND_RCVD field will be reset to NO. The _ state of 
FSM_CONVERSATION may be changed. See below for additional outputs. 


If a CONVERSATION_FAILURE has’ been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the SEND_ERROR to RESOURCE_FAILURE. 


If RECEIVE_ERROR has been received from HS or no error’ records have’ been 
received, further processing of the SEND_ERROR is performed, depending upon 
the state of the conversation. 


Referenced procedures, FSMs, and data structures: 


RECEIVE_RM_OR_HS_TO_PS_RECORDS page 5.1-51 
SEND_ERROR_DONE_PROC page 5.1-55 
SEND_ERROR_IN_RECEIVE_STATE page 5.1-56 
SEND_ERROR_IN_SEND_STATE page 5.1-57 
SEND_ERROR_TO_HS_PROC page 5.1-58 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
A-6 


RCB page 
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Find the RCB for the conversation identified in the RESOURCE parameter. C | 
If executing FSM_CONVERSATION(S, SEND ERROR, RCB) would cause a oe 
state-check (>) condition then 
SET the RETURN_CODE of the SEND_ERROR verb to PROGRAM_STATE_CHECK. 
Else : 
Call RECEIVE _RM_OR_HS_TO PS RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR or CONV_FAILURE_SON (see Note 1) 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-65). 
If the state of FSM_ERROR_OR_FAILURE is CONV_FAILURE_SON then 
Set the RETURN_CODE of the SEND_ERROR verb to RESOURCE_FAILURE_RETRY. 
Else | | 
Set the RETURN_CODE of the SEND_ERROR verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When NO_REQUESTS or RCVD_ERROR (see Note 2) | 
Select based on the state of FSM_CONVERSATION (page 5.1-65): 
When SEND_STATE 
Call SEND_ERROR_IN_SEND_STATE(SEND_ERROR verb parameters, RCB) (page 5.1-57). 
When RCVD_CONFIRM, RCVD_CONFIRM_SEND, or RCVD_CONFIRM_DEALL 
Call SEND_ERROR_TO_HS PROC(RCB) (page 5.1-58). 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-65). - 
Call SEND_ERROR_DONE_PROC(SEND_ERROR verb parameters, RCB) (page 5.1-55). \ 
When RCV_STATE 
Call SEND_ERROR_IN_RECEIVE_STATE(SEND_ERROR verb parameters, RCB) (page 5.1-56). 
Set REQUEST_TO_SEND RECEIVED of the SEND_ERROR verb to RCB.RQ_TO_SEND_RCVD. 
Set RCB.RQ_TO_SEND_RCVD to NO. 


TEST_PROC 
_ 
_> 
FUNCTION: This procedure performs the processing of a TEST record. 
The procedure first receives any records from RM and HS. It then tests wheth- 
er the conversation has been posted or whether REQUEST_TO_SEND notification 
has been received from the remote transaction. The RETURN_CODE field of TEST 
records the result of the test. 
INPUT: TEST record 


OUTPUT: The RETURN_CODE field of TEST records the result of the test. If the TP is 
informed that a RQ_TO_SEND has been received, then the RCB.RQ_TO_SEND_RCVD |,” ~ 


/ 
field is reset to NO. le 
Referenced procedures, FSMs, and data structures: 
DEQUEUE_FMH7_PROC page 5.1-34 
RECEIVE_RM_OR_HS_TO_PS_RECORDS page 5.1-51 
TEST_FOR_POST_SATISFIED page 5.1-60 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
FSM_POST page 5.1-68 
RCB page A-6 
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Set the RETURN_CODE of the TEST verb of TEST to OK. 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
Select based on the TEST parameter of the TEST verb: 
When POSTED 
If executing FSM_CONVERSATION(S, TEST_POSTED, RCB) (page 5.1-65) 
would cause a state-check (>) condition then 
Set the RETURN_CODE of the TEST verb to PROGRAM_STATE_CHECK. 
Else 
If state of FSM_POST is RESET then 
Set the RETURN_CODE of the TEST verb to POSTING_NOT_ACTIVE. 
Else 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_SON 
Set the RETURN_CODE of the TEST verb to RESOURCE_FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When CONV_FAILURE_PROTOCOL_ERROR 
Set the RETURN_CODE of the TEST verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
- When RCVD_ERROR 
C If the FMH7 is not in the RCB.HS_TO_PS BUFFER_LIST then 
\ 


C- Find the RCB for the resource identified in the RESOURCE field of the TEST record. 


Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) 
(page 5.1-51). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 
Set the RETURN_CODE of the TEST verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the TEST verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC», RCB) (page 5.1-65). 
Else 
Call DEQUEVE_FMH7_PROC( TEST verb parameters, RCB) (page 5.1-34). 
When NO_REQUESTS 
eee Call TEST_FOR_POST_SATISFIED(RCB) (page 5.1-60). 
( ‘ Select on state of FSM_POST: 
Nore When PEND_POSTED 
Set the RETURN_CODE of the TEST verb to UNSUCCESSFUL. 
When POSTED 
If an FMH-7 is the next thing to process then 
Call DEQUEUE_FMH7_PROC( TEST verb parameters, RCB) 
(page 5.1-34). | 
Else | 
Set the RETURN_CODE subcode to NOT_DATA or DATA as 
appropriate. 
If the state of FSM_CONVERSATION is not END_CONV then (page 5.1-65). 
Call FSM_CONVERSATION(S, TEST, RCB) (page 5.1-65). 
Call FSM_POST (page 5.1-68) and pass it a TEST signal. 
When REQUEST_TO_SEND_RECEIVED 
- If executing FSM_CONVERSATION(S, TEST_RQ_TO_SEND_RCVD, RCB) (page 5.1-65) 
would cause a state-check (>) condition then | 
Set the RETURN_CODE of the TEST verb to PROGRAM_STATE_CHECK. 
Else 
If RCB.RQ TO SEND _RCVD is YES then 
Set RCB.RQ_TO_SEND RCVD to NO. 
Else 
Set the RETURN_CODE of the TEST verb to UNSUCCESSFUL. 
Call FSM_CONVERSATION(S, TEST_RQ_TO_SEND_RCVD, RCB) (page 5.1-65). 
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COMPLETE_CONFIRM_PROC 


FUNCTION: 


INPUT: 
OUTPUT : 


NOTES: 


This procedure completes the processing of a CONFIRM verb. 


It 1s called by CONFIRM_PROC (page 5.1-12) when no error or’ failure condi- 
tions are indicated by FSM_ERROR_OR_FAILURE (page 5.1-67). The action of this 
procedure is dependent on the state of the conversation, as described below. 


CONFIRM parameters and the RCB corresponding to the resource specified in the 
CONFIRM verb 


The MU.PS_TO_HS.TYPE field is set before sending the MU to HS. See Notes for 
additional outputs. 


If FSM_CONVERSATION is in the SEND_STATE, an MU with MU.PS_TO_HS.TYPE field 
set to CONFIRM is sent to HS. 


If FSM_CONVERSATION is in the PREPARE_TO_RECEIVE_DEFER state, an MU with 
MU.PS TO_HS.TYPE field set to PREPARE_TO_RCV_CONFIRM is sent to HS. 


If FSM_CONVERSATION is in the DEALLOCATE_DEFER state, an MU with 
MU.PS_TO_HS.TYPE field set to DEALLOCATE_CONFIRM is sent to HS. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
WAIT_FOR_CONFIRMED_PROC page 5.1-61 
FSM_CONVERSATION | page 5.1-65 
MU page A-29 
RCB page A-6 


If a send MU buffer does not exist then 


Call CREATE_ 


AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Select based on the state of FSM_CONVERSATION (page 5.1-65): 
When SEND_STATE (see Note 1) 
Set MU.PS_TO_HS.TYPE to CONFIRM and send the MU Recor? to HS. 
When PREP_TO_RCV_DEFER (see Note 2) 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_CONFIRM_. SHORT or PREPARE_TO_RCV_CONFIRM_LONG as 
indicated by RCB.LOCKS and send the MU record to HS. 
When DEALL_DEFER (see Note 3) 
Set MU.PS_TO_HS.TYPE to DEALLOCATE_CONFIRM and send the MU record to HS. 
Call FSM_CONVERSATION(S, CONFIRM, RCB) (page 5.1-65). 
Call WAIT_FOR_CONFIRMED_PROC(CONFIRM verb parameters, RCB) (page 5.1- 61). 
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COMPLETE_DEALLOCATE_ABEND_PROC 


COMPLETE_DEALLOCATE_ABEND_PROC 


FUNCTION: 


INPUT : 


OUTPUT : 


This procedure completes the processing of a DEALLOCATE verb that specifies 
TYPE = ABEND. 


If an MU buffer for storage of data sent by the transaction program currently 
exists, PS sends it to the HS and another MU buffer is obtained for storing 
the FMH-73; otherwise, a new MU buffer is obtained for storing the FMH-7. PS 
creates an FMH-7 and places it in the newly-created MU. The FMH-7 carries 
sense data indicating DEALLOCATE_ABEND. If any log data is associated with 
the DEALLOCATE, PS creates an Error Log GDS variable (see SNA Formats) and 


places it in‘the MU to be sent to the partner LU. PS also places the GDS var- 
iable (minus the LL and GDS ID fields) in the local LU's system error log. PS 
then sends the MU, containing the FMH-7 and optional Error Log GDS variable, 
to HS. 


DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE 


One or more MUs are sent to HS. 
logged. 


Any log data supplied with the DEALLOCATE is 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
SEND_DATA_BUFFER_MANAGEMENT page 5.1-54 
MU page A-29 


Set sense data based on the TYPE parameter of the DEALLOCATE verb as follows: 
to X'08640000' if ABEND_PROG, or 
to X'08640001' if ABEND_SVC, or 
to X'8640002'if ABEND_TIMER. 
If a send MU buffer exists then 
Send the MU record to HS. 
Call CREATE_AND_INIT_LIMITED MU(RCB, created MU) (page 5.1-30). 
If LOG_DATA parameter has been supplied then 
Store the FMH-7 indicating log data present and sense data in the MU. 
Create an Error Log GDS variable (see SNA Formats for format). 
Call SEND_DATA_BUFFER_MANAGEMENT(Error log GDS variable, RCB) (page 5.1-54) 
to concatenate the error log GDS variable to the FMH-7 in the MU. 
Log the Error Log GDS variable in the system error log. 


Else 


Store the FMH-7 with sense data but no log data present in the MU. 
Set MU.PS_TO_HS.TYPE to DEALLOCATE_FLUSH and send the MU record to HS. 


CONVERSATION_FAILURE_PROC 


FUNCTION: 
INPUT : 


OUTPUT : 


This procedure processes CONVERSATION_FAILURE records. 


A CONVERSATION_FAILURE record 


FSM_ERROR_OR_FAILURE is set to the appropriate state. PS remembers the con- 
versation failure until that information can be relayed to the transaction 
program. If posting 1s active, FSM_POST is called to change the state to 
POSTED. 


Referenced procedures, FSMs, and data structures: 


FSM_ERROR_OR_FAILURE page 5.1-67 
FSM_POST page 5.1-68 
CONVERSATION_FAILURE page A-21 
RCB page A-6 
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Find the RCB for the conversation identified in the RESOURCE parameter. {~ 
If the RCB for the CONVERSATION_FAILURE record is found, then a 
If CONVERSATION_FAILURE.REASON is PROTOCOL_VIOLATION then . 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it a CONV_FAIL_PROTOCOL signal. 
Else 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it a CONV_FAIL_SON signal. 
If the state of FSM_POST is PEND_POSTED then 
Call FSM_POST (page 5.1-68) and pass it a POST signal. 


CREATE_AND_INIT_LIMITED_MU 


FUNCTION: This procedure creates and initializes an MU ina buffer from the limited 
buffer pool associated with the LIMITED_BUFFER_POOL_ID value stored in the 
RCB. 


INPUT: The RCB corresponding to the conversation for which the MU is being requested. 


OUTPUT : Appropriate fields in the MU are initialized, the MU is returned to the call- 
ing procedure. 


NOTE : As a result of a race condition, the half-session for this PS may have been 
destroyed and PS has not received the CONVERSATION_FAILURE record from RM. 
When the half-session is destroyed, the POOL for the buffers is also 
destroyed; thus, the attempt to retrieve a POOL buffer will fail with a 
BAD_POINTER return code. The calling tree structure of the PS process 
requires that a buffer be present, so a demand buffer is obtained before 
returning from this procedure. Later, this demand buffer will be freed when 
PS attempts to send the buffer to HS and discovers that HS has been destroyed. 


Referenced procedures, FSMs, and data structures: 
MU . page A-29 
RCB page A-6 


Get buffer for MU-buffer size is RCB.SEND_RU_SIZE. 


Call buffer manager (GET_BUFFER, limited buffer pool ID, wait) to create a 
MU buffer; the buffer from this pool will be equal to the SEND_RU_SIZE / 
value stored in the RCB (Appendix B). Re 
If the buffer manager return code is BAD_POINTER (see Note) then ; 
Call buffer manager (GET_BUFFER, demand, buffer size, wait) to create a buffer 
for the MU record; specify the buffer size to be RCB.SEND_RU_SIZE plus the 
length of the MU overhead (Appendix B). 


Initialize fields in the MU 


Set MU.HEADER_TYPE to PS_TO_HS. 

Set MU.PS_TO_HS.BRACKET_ID to RCB.BRACKET_ID. 

Set MU.PS TO_HS.PS_TO_HS_VARIANT to SEND_DATA_RECORD. 

Set MU.PS_TO_HS.ALLOCATE to NO. 

Set MU.PS TO_HS.FMH to NO. 

Set MU.PS_TO_HS.TYPE to FLUSH. 

Set MU.DCF to indicate the length of data and the RH field. 


The MU is available for storing data from the TP. 
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DEALLOCATE_ABEND_PROC 


; 

1 

' 

C ° 
— 


FUNCTION: This procedure is invoked when the TYPE parameter of DEALLOCATE verb is 
ABEND PROG, ABEND SVC, or ABEND_TIMER. 


PS first receives any records from RM and HS. Appropriate action is taken 
depending upon which, if any», record was received and upon the state of the 
conversation. The state of the conversation and the information in the 
HS _TO_PS_BUFFER_LIST determine whether or not a SEND_ERROR MU is sent to HS 
prior to sending the FMH-7 that is created as a result of the DEALLOCATE (TYPE 
= ABEND_*). Receipt of certain types of information (e.g., notification that 


the conversation has been deallocated by the partner transaction program) 
causes PS to return to the transaction program without taking any action. 


INPUT: DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE 
OUTPUT : Depending upon the state of the conversation and the information contained in 
the HS_TO_PS BUFFER_LIST, an FMH-7 (possibly preceded by a SEND_ERROR MU) is 
i created and sent to HS, or no output is created. All received MUs are purged 
C ) from the HS_TO_PS_BUFFER_LIST before returning to the transaction program. 
Referenced procedures, FSMs, and data structures: 
COMPLETE_DEALLOCATE_ABEND_PROC page 5.1-29 
END_CONVERSATION_PROC page 5.1-34 
RECEIVE_RM_OR_HS_TO_PS_RECORDS | page 5.1-51 
SEND_ERROR_TO_HS_PROC page 5.1-58 
WAIT_FOR_SEND_ERROR_DONE_PROC page 5.1-64 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 
q * Call RECEIVE_RM_OR_HS_TO_PS_RECORDS( empty SUSPEND_LIST) (page 5.1-51). 
go If the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is NO_REQUEST or RCVD_ERROR then 


Select based on the state of FSM_CONVERSATION (page 5.1-65): 
When RCV_STATE 
If DEALLOCATE_FLUSH has not been received on the conversation then 
Call SEND_ERROR_TO_HS_PROC(RCB) (page 5.1-58). 
Call WAIT_FOR_SEND_ERROR_DONE_PROC(DEALLOCATE parameters, RCB) (page 5.1-64). 
When RCVD_CONFIRM, RCVD_CONFIRM SEND, or RCVD_CONFIRM_DEALL 
Call SEND_ERROR_TO_HS_PROC(RCB) (page 5.1-58). 
Call COMPLETE_DEALLOCATE_ABEND_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-29). 
When SEND STATE, PREP_TO_RCV_DEFER, or DEALL_DEFER 
Call COMPLETE_DEALLOCATE_ABEND_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-29). 


yee Set the RETURN_CODE of the DEALLOCATE verb to OK. 

— Call FSM_CONVERSATION(S, DEALLOCATE_ABEND, RCB) (page 5.1-65). 
ae Call END_CONVERSATION_PROC(RCB) (page 5.1-34). 

oe 
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DEALLOCATE_CONFIRM_PROC 


FUNCTION: This procedure is invoKed when DEALLOCATE TYPE(CONFIRM) or DEALLOCATE 
TYPE(SYNC_LEVEL) is issued for a conversation whose SYNC_LEVEL is CONFIRM. . 


PS first retrieves any records from HS. Appropriate action is taken depending 
upon which, if anys record was received. ‘ 


INPUT : DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE ) 


OUTPUT : See below. 
NOTES: 1. If a CONVERSATION_FAILURE has been received from the resources manager, PS 


returns to the transaction program after setting the RETURN_CODE parameter of 
the DEALLOCATE to RESOURCE_FAILURE. ‘ 


If a RECEIVE_ERROR has been received from HS» PS sends a SEND_DATA record with. 
the MU.PS_TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in 
the RCB send buffer was purged when the RECEIVE_ERROR record was received. ) 
PS then waits for the expected FMH-7 error message to arrive. The RETURN_CODE 
parameter of the CONFIRM is set based on the sense data carried in the FMH-7. 


If no error or failure condition has occurred, PS sends an MU with the 
MU.PS_TO_HS.TYPE field set to DEALLOCATE_CONFIRM to HS. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
DEQUEVE_FMH7_PROC page 5.1-34¢ 
RECEIVE RM_OR_HS_TO_PS_RECORDS page 5.1-51 
WAIT_FOR_CONFIRMED_._PROC page 5.1-6l Bs 
FSM_CONVERSATION ) page 5.1-65 ~ : 
FSM_ERROR_OR_FAILURE page 5.1-67 Me 
MU page A-29 4 
RCB page A-6 
If the data sent by TP is not at a logical record boundary then 
Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 
Call FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-65). 
Call RECEIVE_RM_OR_HS TO PS _RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR (see Note 1) 
Set the RETURN_CODE of. the DEALLOCATE verb to RESOURCE_FAILURE_NO_RETRY. er 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When CONV_FAILURE_SON (see Note 1) \ 


Set the RETURN_CODE of the DEALLOCATE verb to RESOURCE_FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE FAILURE_RC,» RCB) (page 5.1-65). 
When RCVD_ERROR (see Note 2) 
If a send MU buffer does not exist then 
Call CREATE_AND_INIT LIMITED MU(RCB, created.MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU to record HS. 
If the FMH7 is not in the RCB.HS_TO_PS BUFFER_LIST then 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 
Else 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND_LIST) (page 5.1-51). 
If the state of FSM_ERROR_OR_FAILURE (page 5.1-67) 1s CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 
Set the RETURN_CODE of the DEALLOCATE verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the DEALLOCATE verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else : 
Call DEQUEUVUE_FMH7_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-34). 


a. 
( : 
“ : 


5.1-32 | SNA LU 6.2 Reference: Peer Protocols 


DEALLOCATE_CONFIRM_PROC 


—- When NO_REQUESTS (see Note 3) 
: If a send MU buffer does not exist then 
KJ Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to DEALLOCATE_CONFIRM and send the MU record to HS. 
Call WAIT_FOR_CONFIRMED_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-61). 


DEALLOCATE_FLUSH_PROC 


FUNCTION: This procedure is invoked when a DEALLOCATE is received that specifies TYPE = 
FLUSH, or TYPE = SYNC_LEVEL and the SYNC_LEVEL of the conversation is NONE. 


After checking that the data for the conversation is on a logical record 


boundary, the procedure accepts any records from RM _ and HS. Appropriate 
- action is taken, depending upon which, if any, record was received (as 
( = reflected by the state of FSM_ERROR_OR_FAILURE). 
/ 


WW" INPUT : DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE 


OUTPUT: DEALLOCATE return code is set. See Notes for additional outputs. 


NOTES: 1. Since the conversation is currently being ended, as a result of processing the 
DEALLOCATE, if a RECEIVE_ERROR has been received from HS, it will be ignored 
by PS. 


If CONVERSATION_FAILURE record has been received from RM, no further records 
are sent to HS. 


\ 

* Referenced procedures, FSMs, and data structures: 
HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
END_CONVERSATION_PROC page 5.1-34 
RECEIVE _RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM ‘CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 

If the data sent by TP is not at a logical record boundary then 
a Set the RETURN_CODE of the DEALLOCATE verb to PROGRAM_STATE_CHECK. 
Else 
ae Call RECEIVE_RM_OR_HS TO PS RECORDS( empty SUSPEND_LIST) (page 5.1-51). 


If state of FSM_ERROR_OR_FAILURE is RCVD_ERROR or NO_REQUESTS (see Note 1) then 
If a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to DEALLOCATE_FLUSH and send the MU record to HS. 
Else (see Note 2) 
Do nothing. 
Set the RETURN_CODE of the DEALLOCATE verb to OK. 
Call FSM_CONVERSATION(S, DEALLOCATE_FLUSH, RCB) (page 5.1-65). 
Call END_CONVERSATION_PROC(RCB) (page 5.1-34¢). 
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DEQUEUE_FMH7_PROC 


INPUT: 


OUTPUT : 


This procedure is invoked upon receipt of a RECEIVE_ERROR from HS. The next 
element expected in the HS_TO_PS BUFFER_LIST is an FMH-7. If the next element 
in the buffer is an FMH-7, it 1s removed from the buffer and processed (the 
RETURN_CODE parameter of the passed verb parameters is set based upon the 
sense data carried in the FMH-7). If the next element is not an FMH-7, the 
partner LU has violated the protocol and the session over which the protocol 


violation occurred is deactivated in an implementation-dependent fashion. 


The transaction program verb parameters currently being processed and the RCB 
corresponding to the resource specified in parameters of the verb 


The state of FSM_POST is changed to RESET. If the record in the buffer is an 
FMH-7, then 1s processed; otherwise, the return code and FSM_CONVERSATION are 
set to indicate the protocol violation, and the session is deactivated. 


Referenced procedures, FSMs, and data structures: 


PROCESS _FMH7_PROC page 5.1-46 
PS_PROTOCOL_ERROR F page 5.0-20 
FSM_CONVERSATION page 5.1-65 
FSM_POST page 5.1-68 
RCB page A-6 


Call FSM_POST (page 5.1-68) and pass it a RECEIVE_IMMEDIATE signal. 


If the first 


entry in RCB.HS_TO_ PS BUFFER_LIST is an FMH-7 then 


Remove the first entry of RCB.HS_TO_PS BUFFER_LIST. 
Call PROCESS _FMH7_PROC(RCB, TP verb parameters) (page 5.1-46). 
Else (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'1008201D') (page 5.0-20). 
Set the RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 


END_CONVERSATION_PROC © 


FUNCTION: 


Referenced procedures, FSMs, and data structures: 


This procedure creates a DEALLOCATE_RCB and sends it to RM. RM's processing 
of this record includes removing the RESOURCE from the RESOURCE_LIST, destroy- 
ing the RCB, and returning a RCB_DEALLOCATED to inform PS that the processing 
is complete. 


Before the DEALLOCATE_RCB record is sent to RM, all MUs’' for the conversation 


are freed. This includes any that might be present in the 
HS_TO_PS_BUFFER_LIST (received MUs), or stored in the RCB (current send MU). 


The RCB corresponding to the resource being deallocated, and RCB_DEALLOCATED 
records from RM. 


DEALLOCATE_RCB record is sent to RM after all received MUs (if present) and 
sending MU (if present) have been freed. 


HS page 6.0-3 
RM page 3-19 
WAIT_FOR_RM_REPLY page 5.1-62 
MU page A-29 
RCB page A-6 
DEALLOCATE_RCB page A-16 
RCB_DEALLOCATED page A-21 
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| Do for each MU in the RCB.HS_TO_PS_BUFFER_LIST (Purge receive buffers) 
oe Call buffer manager (FREE_BUFFER, buffer address) (Appendix B). 
If a send MU buffer exists then (Purge the send buffer) 
Call buffer manager (FREE_BUFFER, buffer address) (Appendix B). 
Create and initialize the DEALLOCATE_RCB record and send it to HS. 
Call WAIT_FOR_RM_REPLY(RCB) to receive RCB_DEALLOCATED from RM (page 5.1-62). 
Destroy the RCB_DEALLOCATED record received from RM. 


GET_DEALLOCATE_FROM_HS 


FUNCTION: This procedure removes from the RCB receive buffer a DEALLOCATE MU. If the 
receive buffer is empty, PS waits until an MU whose MU.HS_TO_PS.TYPE field is 
set to DEALLOCATE is received from HS. 


C ) This procedure is invoked only when the next element expected in the RCB 

a receive buffer is a DEALLOCATE MU. This situation occurs, for example, when 
PS has received an FMH-7 whose sense code indicates an allocation error. The 
FMH-7 1s followed by a notification that the conversation is being deallo- 
cated. It is PS's responsibility, rather than the transaction program's, to 
receive and process the deallocation notification. 


The transaction program verb (TRANSACTION_PGM_VERB) currently being processed 
and the entry in the RCB_LIST corresponding to the resource specified in the 
current TRANSACTION _PGM_VERB 


OUTPUT: The DEALLOCATE MU is removed from the HS_TO_PS_BUFFER_LIST receive buffer. 
s 
es Referenced procedures, FSMs, and data structures: 
=" : GET_END_CHAIN_FROM_HS page 5.1-36 
PS PROTOCOL_ERROR page 5.0-20 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


Call GET_END_CHAIN_FROM_HS(RCB) (page 5.1-36). 


| Remove the DEALLOCATE from the buffer. 
gr 


- | Select based on the following conditions: . 
When the end-of-chain type is DEALLOCATE_FLUSH or DEALLOCATE_CONFIRM 
Do nothing. 
When the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is 
CONV_FAILURE_PROTOCOL_ERROR or CONV_FAILURE_SON 
Do nothing. 
Otherwise (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'1008201D') (page 5.0-20). 
Set the RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call RCB.FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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GET_END_CHAIN_FROM_HS 


FUNCTION: 


INPUT : 


OUTPUT: 


NOTES: 1. 


This procedure is invoked after PS sends a SEND_ERROR record to HS (as a 
result of either 1) a SEND_ERROR, DEALLOCATE (TYPE = ABEND_PROG, ABEND_SVC, 
ABEND_TIMER) issued for the conversation while it is in the receive state or 
2) an invalid Attach resulting in an FMH-7 being sent). This procedure waits 
for a MU whose MU.HS_TO_PS.TYPE field indicates an end-of-chain type is 
received from HS. End-of-chain types include CONFIRM, PREPARE_TO_RCV_CONFIRM, 
PREPARE_TO_RCV_FLUSH, DEALLOCATE_CONFIRM, and DEALLOCATE_FLUSH. 


The RCB corresponding to the conversation for which the end-of-chain type is 
desired 


RCB.RQ_TO_SEND_RCVD may be updated. All records received from HS are 
destroyed or FREEd, as appropriate for the record. The fields in the RCB are 
reset after the end-of-chain type is received. See Notes for additional out- 
puts. 


Receipt of a CONVERSATION_FAILURE record will be regarded as an implied 
end-of-chain type. | 


If a REQUEST_TO_SEND record is received, PS stores that information in the RCB 
to be relayed to the transaction program at a later time, and continues to 
wait for the end-of-chain type. 


If a RECEIVE_ERROR record is received, no action is taken. PS_ continues to 
wait for the end-of-chain type to arrive. This situation occurs if, imme- 
diately prior to issuing the SEND_ERROR or DEALLOCATE (TYPE = ABEND_*), the 
transaction program issued a PREPARE_TO_RECEIVE (TYPE = FLUSH) or PRE- 
PARE_TO_RECEIVE (TYPE = SYNC_LEVEL) and the SYNC_LEVEL of the conversation is 
NONE, and the partner transaction program (while still in RECEIVE state) 
issues a SEND_ERROR or DEALLOCATE (TYPE = ABEND_*). 


When PS sends SEND_ERROR to HS, it begins to purge any data it receives from 
HS until a record indicating end-of-chain type is received. 


Referenced procedures, FSMs, and data structures: 


CONVERSATION_FAILURE_PROC page 5.1-29 
PS_ PROTOCOL: ERROR . page 5.0-20 
FSM_CONVERSATION | page 5.1-65 
MU page A-29 
RCB page A-6 


Determine if end-of-chain type is already in buffer. | 


If end-of-chain type has not been received for this conversation then 
Do for each MU in the RCB.HS TO_PS_ BUFFER_LIST while an end-of-chain 
type has not arrived: 
If MU.HS_TO_PS.TYPE is an end-of-chain type then 
Save the end-of-chain type for later processing. 
Call buffer manager (FREE_BUFFER, buffer address). 


Wait for the end-of-chain type to arrive. 


Do while the end-of-chain type has not been received: 
Find a CONVERSATION_FAILURE, REQUEST_TO_SEND, RECEIVE_ERROR, or MU 
record for this conversation. 
Select based on the record found: 
When CONVERSATION_FAILURE (see Note 1) 
Call CONVERSATION_FAILURE_PROC with RECORD (page 5.1-29). 
The CONVERSATION_FAILURE is treated as an end-of-chain indication. 
When REQUEST_TO_SEND (see Note 2) 
Set RCB.RQ_TO_SEND_RCVD to YES. 
Destroy the REQUEST_TO_SEND record. 
When RECEIVE_ERROR (see Note 3) 
Destroy the RECEIVE_ERROR record. 
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When MU (see Note 4) 
If MU.HS _TO_PS.TYPE is an end-of-chain type then 
Save the end-of-chain type for later processing. 
Call buffer manager (FREE_BUFFER, buffer address). 
Otherwise 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'10010000') (page 5.0-20). 
Call FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-65). 
Update the fields in the RCB to reflect the receipt of the end-of-chain type. 


OBTAIN_SESSION_PROC 


FUNCTION: This procedure handles the acquisition of a session for use by a conversation 


resource. 


This procedure sends a GET_SESSION record to the resources manager and waits 


for a SESSION_ALLOCATED reply. 


The RCB corresponding to the conversation that is to use the obtained session 
and the ALLOCATE verb are passed as a parameters to this procedure. SES- 


SION_ALLOCATED is received from RM. 


OUTPUT : A GET_SESSION record is sent to RM, and the SESSION_ALLOCATED record is 


destroyed. If a session is obtained, an MU is_ created, 


and 


the PERMA- 


NENT_BUFFER_POOL_ID, and LIMITED_BUFFER_POOL_ID fields are set along with the 


send MU.PS_TO_HS.ALLOCATE field; otherwise, these fields remain as initial- 
ized. Also» the RETURN_CODE on the ALLOCATE verb can be updated to reflect 
detected errors. 


The resources manager returns to PS an ALLOCATE_FAILURE return code to a ses- 
(LU name, mode 
name) pair are active and a condition (either temporary or permanent, as 
reflected in the return code) exists such that no sessions can. currently be 


sion allocation request when no sessions having the specified 


activated. 


. 'The resources manager returns to PS a SYNC_LEVEL_NOT_SUPPORTED return code to 
a session allocation request when a session having the specified (LU name, 
mode name) pair is active, but the synchronization level specified by the 


transaction program on ALLOCATE is not supported by the partner LU. 


Referenced procedures, FSMs, and data structures: 


RM 
CREATE_AND_INIT_LIMITED_MU 
WAIT_FOR_RM_REPLY 

MU 

RCB 


GET_SESSION 
SESSION_ALLOCATED 


page 
page 
page 
page 
page 
page 
page 
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Create and initialize the GET_SESSION record and send it to RM. | q : 
Call WAIT_FOR_RM_REPLY (page 5.1-62) to receive SESSION ALLOCATED. | 
Select based on the RETURN_CODE of the SESSION_ALLOCATED record: 
When OK 
Set RCB.SEND_RU_SIZE to SESSION_ALLOCATED.SEND_RU_SIZE. 
Set RCB.LIMITED BUFFER_POOL_ID to SESSION_ALLOCATED.LIMITED_BUFFER_POOL_1ID. 
Set RCB.PERMANENT_BUFFER_POOL_ID to SESSION_ALLOCATED.PERMANENT_BUFFER_POOL_ID. 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
If SESSION_ALLOCATED.IN_CONVERSATION is YES then 
Set the send MU.PS_TO_HS.ALLOCATE to NO. 
Else 
Set the send MU.PS_TO_HS.ALLOCATE to YES. 
Otherwise 
Set the RETURN_CODE of the ALLOCATE verb to ALLOCATION_ERROR. 
Select based on the RETURN_CODE of the SESSION_ALLOCATED record: 
When UNSUCCESSFUL_RETRY 
Set the subcode of the ALLOCATE verb to ALLOCATION_FAILURE_RETRY. 
When UNSUCCESSFUL_NO_RETRY | 
Set the subcode of the ALLOCATE verb to ALLOCATION_FAILURE_NO_RETRY. 
When SYNC_LEVEL_NOT_SUPPORTED 
Set the subcode of the ALLOCATE verb to SYNC_LEVEL_NOT_SUPPORTED_BY_LU. ; C 


Destroy SESSION_ALLOCATED record. 


PERFORM_RECEIVE_EC_PROCESSING 


FUNCTION: This procedure processes the end-of-chain type that has been received and 
saved for this conversation. ? 


This procedure is called only if the end-of-chain type received is a value 
other than NOT_END_OF_DATA. 


INPUT: The RCB corresponding to the resource specified in the verb parameters, and 
RECEIVE verb parameters | 


OUTPUT : The return code field of the RECEIVE verb is updated to the appropriate value. 
The state of FSM_CONVERSATION may be changed. 


Referenced procedures, FSMs, and data structures: 


PS_PROTOCOL_ERROR | page 5.0-20 Naw 
FSM_CONVERSATION : - page 5.1-65 


RCB . page A-6 
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C | Select based on the following conditions: 
ow When the data sent by the TP is not on a logical record boundary 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'10010000') (page 5.0-20). 
Set the RETURN_CODE of the RECEIVE verb to RESOURCE_FAILURE_NO_ RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When RCB.SYNC_LEVEL 1s NONE and the end-of-chain type is CONFIRM; 
PREPARE_TO_RCV_ CONFIRM, or DEALLOCATE_CONFIRM 
Call PS_PROTOCOL_ERROR (RCB.HS_ID, X'‘'10010000') (page 5.0-20). 
Set the RETURN_CODE of the RECEIVE verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC», RCB) (page 5.1-65). 
Otherwise 
Select based on the end-of-chain type received: 
When CONFIRM 
Set the RETURN_CODE of the RECEIVE verb to OK. 
Set the WHAT_RECEIVED parameter of the RECEIVE verb to CONFIRM. 
Call FSM_CONVERSATION(R, CONFIRM_INDICATOR, RCB) (page 5.1-65). 
WHEN PREPARE_TO_RCV_CONFIRM 
Set the RETURN_CODE of the RECEIVE verb to OK. 
Set the WHAT_RECEIVED parameter of the RECEIVE verb to CONFIRM_SEND. 
_ Call FSM_CONVERSATION(R, CONFIRM_SEND_INDICATOR, RCB) (page 5.1-65). 
: WHEN PREPARE_TO_RCV_FLUSH 
C Set the RETURN_CODE of the RECEIVE verb to OK. 
Set the WHAT_RECEIVED parameter of the RECEIVE verb to SEND. 
Call FSM_CONVERSATION(R, SEND_INDICATOR, RCB) (page 5.1-65). 
WHEN DEALLOCATE_CONFIRM 
Set the RETURN_CODE of the RECEIVE verb to OK. 
Set the WHAT_RECEIVED parameter of the RECEIVE verb to CONFIRM_DEALLOCATE. 
Call FSM_CONVERSATION(R, CONFIRM_DEALLOCATE_INDICATOR, RCB) (page 5.1-65). 
WHEN DEALLOCATE_FLUSH 
Set the RETURN_CODE of the RECEIVE verb to DEALLOCATE_NORMAL. 
Call FSM_CONVERSATION(R, DEALLOCATE_NORMAL_RC, RCB) (page 5.1-65). 
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PERFORM_RECEIVE_ PROCESSING 


PERFORM_RECEIVE_PROCESSING 


FUNCTION: This procedure checks the RCB.HS_TO_PS BUFFER_LIST receive buffer to see if 
any information has arrived for the conversation specified in the passed 
RECEIVE verb parameters and, if so, updates the verb parameters’ to reflect 
that information. Examples of the type of information that can be received 
include a request for confirmation, notification that the partner transaction 
program has deallocated the conversation, and conversation data. 


If no information has been received for the specified conversation, the 
RETURN_CODE parameter is set to UNSUCCESSFUL and control is returned to the 
calling procedure. 


INPUT: The RCB corresponding to the resource specified in the verb parameters, and 
RECEIVE verb parameters 


OUTPUT : The information is copied from the MU into the RECEIVE verb data buffer to be 
passed up to the TP. If the data in the MU is exhausted, the MU is freed and 
the next MU in the receive buffer, if present, will begin to be processed. 


PS performs an optional receive check to determine if the partner LU has vio- 
lated protocols by allowing the partner transaction program to invalidly trun- 
cate the logical record the program was in the process of sending (1i.e., the 
partner transaction program issued a verb, such as CONFIRM, before completing 
the current logical record). Only an FMH-7 can validly be received before the 
current logical record is completed, in which case the FMH-7 contains sense 
data indicating data truncation. 


PS performs an optional receive check to determine if the partner LU has vio- 
lated the protocols by allowing the partner transaction program to issue a 
request for confirmation on a conversation whose SYNC_LEVEL is NONE. 


Referenced procedures, FSMs, and data structures: 

PERFORM_RECEIVE_EC_PROCESSING page 5.1-38 
PROCESS_FMH7_PROC page 5.1-46 
PROCESS_DATA_PROC page 5.1-43 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
RCB -_page A-6 


Set MU_PTR to the first MU in the RCB.HS_TO_PS_BUFFER_LIST. 


If the MU_PTR is not NULL or end chain indicator is not NOT_END_OF_DATA then 
Do while the MU_PTR is not NULL and posting condition is not satisfied: 
If an FMH_7 is contained in the MU then 
If no data has been copied to pass to the TP then 
Call PROCESS _FMH7_PROC(RCB, RECEIVE verb parameters) (page 5.1-46). 
Set the MU_PTR to the next MU in the RCB.HS_TO_PS BUFFER_LIST. 
Else 
If the MU has more data to be received then 
Call PROCESS DATA_PROC(RCB, RECEIVE verb parameters, DATA_NEEDED) (page 5.1-43). 


If the data in the MU has all been received then 
If MU.HS _TO_PS.TYPE is NOT_END_OF_DATA then 
Call buffer manager (FREE_BUFFER, buffer address) (Appendix B). 
Set MU_PTR to the next MU in the RCB.HS_TO_PS BUFFER_LIST. 
Else 
End-of-chain type has been received; posting is satisfied. 


If no data is being returned to the TP and an FMH_7 was not processed and the end-of-chain 
type was not NOT_END_OF_DATA then 
Call PERFORM_RECEIVE_EC_PROCESSING(RCB, RECEIVE verb parameters) (page 5.1-38). 
End-of-chain type is returned to the TP. 


Else (MU_PTR is NULL or end-of-chain type is not NOT_END_OF_DATA) 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR 
Set the RETURN CODE of the RECEIVE verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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PERFORM_RECEIVE_PROCESSING 


When CONV_FAILURE_SON 


pe Set the RETURN_CODE of the RECEIVE verb to RESOURCE_FAILURE_RETRY. 
( Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
east Otherwise 


If the RECEIVE verb is a RECEIVE_IMMEDIATE verb and no data is being 
returned to the TP then 
Set the RETURN_CODE of the RECEIVE_IMMEDIATE verb to UNSUCCESSFUL. 
Else 
Set the RETURN_CODE parameter of the RECEIVE verb to OK. 


PREPARE_TO_RECEIVE_CONFIRM_PROC 


FUNCTION: This procedure continues the processing of a PREPARE_TO_RECEIVE when TYPE = 
SYNC_LEVEL and the SYNC_LEVEL of the conversation is CONFIRM. 


= INPUT: PREPARE_TO_RECEIVE verb parameters and the RCB corresponding to the resource 
; specified in the PREPARE TO RECEIVE 


OUTPUT : Depending on the state of FSM_ERROR_OR_FAILURE, the MU.PS_TO_HS.TYPE field may 
be set prior to sending the MU to HS. See Notes for additional outputs. 


NOTES: 1. If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the PREPARE_TO_RECEIVE verb to RESOURCE_FAILURE. 


If a RECEIVE_ERROR has been received from HS, PS' sends the current send MU 
record with the MU.PS_TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. 
(Any data in the RCB send buffer was purged when the RECEIVE_ERROR record was 


= received.) PS then waits for the expected FMH-7 error message to arrive. The 
) RETURN_CODE parameter of the CONFIRM is set based on the sense data carried in 
the FMH-7. 


If no error or failure condition has occurred, PS sends the current send MU 
with the MU.PS_TO_HS.TYPE field set to PREPARE_TO_RCV_CONFIRM to HS and waits 
‘for a CONFIRMED reply. 


Referenced procedures, FSMs> and data structures: 


HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
DEQUEVUE_FMH7_PROC page 5.1-34 
“3 ~ RECEIVE _RM_OR_HS_ TO _PS_RECORDS page 5.1-51 
q ! WAIT_FOR_CONFIRMED_PROC page 5.1-61 
ee FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 

MU q page A-29 

RCB page A-6 


Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_CONFIRM, RCB) (page 5.1-65). 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(empty SUSPEND LIST) (page 5.1-51). 


Select based on state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR (see Note 1) 
Set the RETURN_CODE of PREPARE_TO_RECEIVE verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When CONV_FAILURE_SON (see Note 1) 
Set the RETURN_CODE of PREPARE_TO_RECEIVE verb to RESOURCE_FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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PREPARE_TO_RECEIVE_CONFIRM_PROC 


5.1-42 


When RCVD_ERROR (see Note 2) 

If a send MU buffer does not exist then 

Call CREATE_AND_INIT_LIMITED_MU(RCB, sestea: MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU record to HS. 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID)(page 5.1-51). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 

If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 

Set the RETURN_CODE of PREPARE_TO_RECEIVE verb to RESOURCE_FAILURE_RETRY. 


Else 


Set the RETURN_CODE of PREPARE_TO_RECEIVE to verb RESOURCE_FAILURE_NO_ RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 


Else 


Call DEQUEUE_FMH7_PROC( PREPARE_TO_RECEIVE verb parameters, RCB) (page 5.1-34). 
When NO_REQUESTS (see Note 3) 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RCV_CONFIRM_SHORT or PREPARE _To_ RCV_CONFIRM_LONG as 
indicated by RCB.LOCKS. 
Call WAIT_FOR_CONFIRMED_PROC( PREPARE_TO_RECEIVE verb parameters, RCB) (page 5.1-61). 


PREPARE_TO_RECEIVE_FLUSH_PROC 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 1. 


This procedure continues the processing of a PREPARE_TO_RECEIVE when TYPE = 
FLUSH, or TYPE = SYNC_LEVEL and the SYNC_LEVEL of the conversation is NONE. 


PREPARE_TO_RECEIVE verb parameters and the RCB corresponding to the resource 
specified in the PREPARE_TO RECEIVE 


The RETURN_CODE is set to OK, the state of FSM_CONVERSATION is changed and an 
MU may be sent to HS. See below for additional output. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA record with 
the MU.PS_TO_HS.TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in 
the RCB send buffer was purged when the RECEIVE_ERROR record was received. ) 
PS then waits for the expected FMH-7 error message to arrive. The RETURN_CODE 
parameter of the CONFIRM is set based on the sense data carried. in the FMH-7. 


If a conversation failure has occurred, no action is taken. PS _ reports the 
error to the transaction program at a later time. 


Referenced procedures, FSMs, and data structures: 


HS ' page 6.0-3 
CREATE_AND_INIT_LIMITED_MU - page 5.1-30 
RECEIVE RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_ CONVERSATION page 5.1-65 
FSM_ERROR_ OR_ FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 


Call RECEIVE_RM_OR_HS_TO_PS_RECORDS( empty SUSPEND_LIST) (page 5.1-51). 


If the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is RCVD_ERROR or NO_REQUESTS then 
If a send MU buffer does not exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 
Set MU.PS_TO_HS.TYPE to PREPARE_TO_RECEIVE_FLUSH and send the MU record to HS. 


Set the RETURN_CODE of the PREPARE_TO_RECEIVE verb to OK. 
Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_ FLUSH, RCB) (page 5.1-65). 
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PROCESS_DATA_PROC 


PROCESS _DATA_PROC 


This procedure handles the processing of MUs from the HS_TO_PS_BUFFER_LIST. 


The procedure first checks to see if the data in the MU being processed is a 
PS header or a logical record having an invalid LL value, in order to take 
appropriate action. . 


If this data is not a PS header or an invalid LL, then further processing of 
the data in the MU occurs as described below. 


The RCB corresponding to the resource specified in the passed RECEIVE verb 
parameters, the MU (contained in the RCB.HS_TO_PS_BUFFER_LIST), and the 
RECEIVE verb parameters. 


The parameters of the RECEIVE_VERB are updated. 


If the data in the MU being processed begins on a logical record boundary 
(i.e., the last data passed to the transaction program was a complete conver- 
sation record or the last remaining portion of a logical record, or no data 
has been passed to the transaction program since it last entered the receive 
state) and both bytes of the next logical record's LL field are present in the 
MU, data is moved from the MU parameter to the DATA parameter of the passed 
RECEIVE verb. 


If the data in the MU being processed begins on a logical record boundary, but 

only the first byte of the next 2-byte LL field is present in the MU, this 

procedure checks to see if any other information has’ been received following 
the first byte of the LL. If the LL has been truncated by receipt of an 
FMH-7, the LL byte is placed in the DATA parameter of the passed RECEIVE verb 
and control is returned to the transaction program. (The FMH-7 is processed 
when the transaction program issues another verb.) If the LL has been trun- 

cated invalidly by receipt of information other than an FMH-7, the partner LU 
has committed a protocol violation and the session over which the conversation 
is occurring is deactivated. If no information follows the first byte of the 

LL, 1t 1s saved in the buffer and control is returned to the transaction pro-. 
gram. (The first byte of the LL is not passed to the transaction program. 

Until the second byte of the 2-byte LL field arrives, PS does not Know if the 

LL is associated with a logical record or with a PS header. ) 


If the data in the passed MU does not begin on a logical record boundary 
(i.e., part, but not all, of a logical record has already been passed to the 
transaction program), data 1s moved from the MU to the DATA parameter of the 
passed RECEIVE verb. 


MUs from the RCB.HS _TO_PS BUFFER_LIST are passed in» one at a time, 
for this procedure to copy the data from the MU into the RECEIVE_* 
verb DATA parameter to be returned to the transaction program. 


While processing the MU, information on the location in the MU, 
location in the logical record, and number of bytes remaining in the 
current logical record is continually updated as the data is copied 
from the MU to the RECEIVE_* verb DATA parameter. 


As the data is copied into the RECEIVE_* verb, one or more of the fol- 
lowing RECEIVE_* verb parameters must also be set accordingly: 


e WHAT_RECEIVED 

@ RETURN_CODE 

e LENGTH of data returned 

See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for 


see 
Notes 1, 2, and 3 for additional information. 
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PROCESS _FMH7_LOG_DATA_PROC 


FUNCTION: 


OUTPUT : 


This procedure is invoked upon encountering an FMH-7 with LOG_DATA following 
it in the HS_TO PS BUFFER_LIST. 


The RETURN_CODE parameter of the passed transaction program verb is set based 
upon the sense data carried in the FMH-7. This procedure simulates a 
RECEIVE_AND_WAIT verb and causes receive processing to take place. The 
RECEIVE_AND_WAIT processing waits for one or more logical records, which con- 
sists of the log data, to arrive from HS. If the sense data’ carried in the 
FMH-7 indicates a type of DEALLOCATE_ABEND_*, this procedure retrieves the 
deallocation notification from the receive buffer before returning to the 
transaction program. 


The RCB corresponding to the resource to which the FMH-7 applies, the 
FMH_SENSE_DATA associated with the error, and the transaction program verb 
currently being processed 


The RETURN_CODE parameter of the verb is set based upon the sense data carried 
in the passed FMH-7. The one or more logical records containing the. Error Log 
GDS variable are placed (minus the LL and GDS ID fields) in the system error 
log of the local LU. 


This error occurs when the FMH-7 specifies that log data follows, but either 
no log data is present, or the logical record containing the log data is 
invalidly truncated by receipt of a CONFIRM (for example). If the error that 
occurred is that the log data was invalidly truncated, the error has already 
been detected by the PERFORM_RECEIVE_PROCESSING procedure, which has already 
appropriately set the return code of the current verb to reflect this error. 


When the sense data in the FMH-7 indicates a type of DEALLOCATE_ABEND_*, a 
deallocation notification is expected. If this expected notification is not 
received, as protocol violation has occurred. The procedure 
GET_DEALLOCATE_FROM_HS performs the appropriate processing, which includes 
placing the conversation in END_CONV state. 


Referenced procedures, FSMs, and data structures: 


GET_DEALLOCATE_FROM_HS page 5.1-35 
PS_PROTOCOL_ERROR page 5.0-20 
SET_FMH7_RC page 5.1-59 
RECEIVE_AND_TEST_POSTING page 5.1-50 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


GET THE ERROR LOG DATA 


Create a RECEIVE _AND_WAIT. and initialize as follows: 


Set RECEIVE 


Set RECEIVE_ 


Set RECEIVE_ 
Set RECEIVE 


AND_WAIT.RESOURCE to RCB.RCB_ID. 
AND_WAIT.FILL to LL. 
AND_WAIT.MAX_LENGTH to X'7FFF'. 
_AND_WAIT.DATA to NULL. 


Call RECEIVE_AND_TEST_POSTING(RCB, RECEIVE _AND_WAIT wens: iearenetare (page 5.1-50) to 
receive the log data following the FMH_7. 
If the RETURN_CODE of the RECEIVE_AND WAIT verb is OK and the WHAT_RECEIVED indicator 
1s DATA_COMPLETE then 
If the GDS ID is X'12E1' then 
Record the log data to the system log. 
Else (see Note 1.) 
Record the error receiving the LOG_DATA to the system log. 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, X'1008201D') (page 5.0-20). 
Call FSM_ERROR_OR_FAILURE SIGNAL(CONV_FAIL_PROTOCOL) (page 5.1-67). 
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PROCESS _FMH7_LOG_DATA_PROC 


Else (see Note 1.) | 
If the RETURN_CODE of the RECEIVE_AND_WAIT verb is RESOURCE_FAILURE_RETRY then 
Record a SON error occurred receiving log data to the system log. 
Else 
Record a PROTOCOL_ERROR occurred to the system log. 
Destroy the created RECEIVE_AND_WAIT verb. 


Set the states of the FSMs 


If the passed sense data is X'08640000', X'08640001', or X'8640002' then (see Note 2. ) 
If the state of FSM_ERROR_OR_FAILURE is NO_REQUESTS then 
Call GET_DEALLOCATE_FROM_HS(verb parameters, RCB) (page 5.1-35). 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Else 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it 
a CONV_FAIL_PROTOCOL signal. 


When CONV_FAILURE_SON 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it 
a CONV_FAIL_SON signal. | 


Otherwise 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 


Set all the RCB receive processing fields to their initial values (processing begins 
anew following receipt of an FMH-7). 
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PROCESS_FMH7_PROC 


FUNCTION: 


OUTPUT : 


This procedure is invoked ~~ upon encountering an FMH-7 in the 
HS_TO_PS_BUFFER_LIST. | 


The RETURN_CODE parameter of the passed transaction program verb is set based 


upon the sense data carried in the FMH-7. If the FMH-7 indicates that log . 


data follows, this procedure simulates a RECEIVE_AND_ WAIT verb and causes 
receive processing to take place. The RECEIVE_AND_WAIT processing waits for a 
logical record, which consists of the log data, to arrive from HS. If the 
sense data carried in the FMH-7 indicates a type of DEALLOCATE_ABEND_* this 
procedure retrieves the deallocation notification from the receive buffer 
before returning to the transaction program. 


The RCB corresponding to the resource to which the FMH-7 applies, the MU con- 
taining the received FMH-7 (contained in the RCB.HS_TO_PS_BUFFER_LIST), and 
the transaction program verb currently being processed 


The RETURN_CODE parameter of the verb is set, based upon the sense data car- 
ried in the passed FMH-7; if log data follows the FMH-7, PS retrieves the log- 


ical record containing the Error Log GDS’ variable and places it (minus the LL 


and GDS ID fields) in the system error log of the local LU. 
Logical record processing begins anew following receipt of an FMH-7. 


When the sense data in the FMH-7 indicates a type of DEALLOCATE_ABEND_*, a 
deallocation notification is expected. If this expected notification is not 
received, as protocol violation has occurred. The procedure 
GET_DEALLOCATE_FROM_HS performs the appropriate processing, which includes 
placing the conversation in END_CONV state. 


Referenced procedures, FSMs, and data structures: 


GET_DEALLOCATE_FROM_HS page 5.1-35 
PROCESS_FMH7_LOG_DATA_PROC page 5.1-44¢ 
PS_PROTOCOL_ERROR | page 5.0-20 
SET_FMH7_RC page 5.1-59 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR__ OR_ FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 


Set the MU_PTR 


to the first entry in the HS_TO_PS_BUFFER_LIST. 


Validate the FMH-7. 


As an implementation-dependent option perform receive checks of the FMH-7. 


If an error is 


found then 


Call PS_PROTOCOL_ERROR(RCB.HS_IS, X'nnnnnnnn') (page 5.0-20) with X'nnnnnnnn' set to: 
X*'10086000 ' (Request Error--FMH Length Incorrect) or 

X'1008200E' (Request Error--Invalid Concatenation Bit). 

Set the RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE _FAILURE_RC» RCB) (page 5.1-65). 

Set RCB.POST_CONDITIONS .MAX_LENGTH to 0. 


Processing necessary as a result of the FMH-7 


Else 
Set all the 
If the data 
Remember 
Save the 


RCB receive processing fields to their initial values (see Note 1). 
in the MU has all been received then 

if the FMH-7 has log data present and the sense data value. 
end-of-chain type for later processing. 


Call buffer manager (FREE_BUFFER, buffer address) (Appendix B). 
Set the MU_PTR to the first entry in the HS_TO_PS_BUFFER_LIST. 
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PROCESS _FMH7_PROC 


Get the log data if present. | 


If the FMH_7 indicates log data is present then 
Call PROCESS_FMH7_LOG DATA_PROC(RCB, FMH_7 sense data, verb parameters) (page 5.1-44). 
Else 
If FMH_SENSE_DATA is X'08640000', X'08640001', or X'08640002' then (see Note 2.) 
If the state of FSM_ERROR_OR_FAILURE is NO_REQUESTS then 
Call GET_DEALLOCATE_FROM_HS(verb parameters, RCB) (page 5.1-35). 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Else 
Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): 
When CONV_FAILURE_PROTOCOL_ERROR 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass 
it a CONV_FAIL_PROTOCOL signal. 
When CONV_FAILURE_SON 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass 
it a CONV_FAIL_SON signal. 
Otherwise 
Call SET_FMH7_RC(RCB, FMH_7 sense data, verb parameters) (page 5.1-59). 
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RCB_ALLOCATED_PROC 


FUNCTION: 


INPUT: 


OUTPUT : 


This procedure performs further processing of an ALLOCATE request. It is 
invoked when PS receives an RCB_ALLOCATED record from the resources manager. 


This procedure sets the RETURN_CODE parameter of the ALLOCATE verb based upon 
the return code field of the RCB_ALLOCATED record. If the return code is OK, 
it finishes initializing the new RCB (i.e., those fields not already initial- 
ized by RM). In addition, if the RETURN_CONTROL parameter of ALLOCATE is 
WHEN_SESSION_ALLOCATED, PS requests that a session be obtained for this con- 
versation. 


If the return code in RCB_ALLOCATED is OK, then RM_ has created an’ RCB and 
entered a RESOURCE entry in the RESOURCE_LIST for the appropriate TCB. 


RCB_ALLOCATED record and ALLOCATE verb parameters 


The ALLOCATE return code and RESOURCE are set. If no errors occur obtaining 
the session, then PS creates an FMH-5 Attach header and either’ stores it in 
the send buffer in the RCB or optionally flushes it, which requires setting 
the MU.PS_TO_HS. TYPE field to FLUSH. An MU is created and 
MU.PS_TO_HS.ALLOCATE set to YES if ALLOCATE( IMMEDIATE) is specified. 


If RETURN_CONTROL = IMMEDIATE, RM has allocated both an RCB and a session as a 
result of receiving ALLOCATE_RCB from PS. 


A return code of UNSUCCESSFUL in reply to an ALLOCATE (RETURN_CONTROL = IMME- 
DIATE) indicates that no first-speaker half-sessions are currently available. 


The resources manager returns to PS a SYNC_LEVEL_NOT_SUPPORTED return code to 
a session allocation request when a session having the specified (LU name, 
mode name) pair is active, but the synchronization level specified by the 
transaction program on ALLOCATE is not supported by the partner LU. 


Referenced procedures, FSMs», and data structures: 


HS | page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
OBTAIN_SESSION_PROC page 5.1-37 
FSM_CONVERSATION page 5.1-65 
RCB_ALLOCATED page A-21 
RCB page A-6 

MU page A-29 
TCB page A-9 
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RCB_ALLOCATED_PROC 


Select based on the RETURN_CODE of the RCB_ALLOCATED record: 
When OK . 
Set the RETURN_CODE of the ALLOCATE verb to OK. 
Find the RCB for the conversation identified by the RCB_ID in the RCB_ALLOCATED record. 
Set the RESOURCE parameter of the ALLOCATE verb to RCB identifier. 
Set the fields in the RCB to their initial values. 


If the RETURN_CONTROL parameter of the ALLOCATE verb is IMMEDIATE then (see Note 1) 
Call CREATE_AND INIT LIMITED _MU(RCB, created MU) (page 5.1-30). 


Set MU.PS_TO_HS.ALLOCATE to YES. 
Else 
Call OBTAIN_SESSION_PROC(RCB, ALLOCATE verb parameters) (page 5.1-37). 
If the RETURN_CODE of the ALLOCATE verb is OK then 
.Build an FMH~-5 Attach (see SNA Formats) with the data in ALLOCATE. 
If the FMH-5 is to be flushed (as an Emp EMCI SAON dependent option) then 
Send the MU record to HS. 
Else (error found during ALLOCATE processing) 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-65). 
When UNSUCCESSFUL (see Note 2) 
Set the RETURN_CODE of the ALLOCATE verb to UNSUCCESSFUL. 
When SYNC_LEVEL_NOT_SUPPORTED 
Find the RCB for the conversation identified by the RCB_ID in the RCB_ALLOCATED record. 
Initialize the allocated RCB. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-65). 
Set the RETURN_CODE of the ALLOCATE verb to ALLOCATION_ERROR with a subcode of 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU (see Note 3). 
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RECEIVE_AND_TEST_POSTING 


FUNCTION: This procedure transfers data from the received MUs into the RECEIVE_AND_WAIT 
data buffer while checking for posting to be satisfied. 


INPUT: RCB of the conversation, and the RECEIVE_AND_WAIT verb 


OUTPUT : Buffer area of the verb is filled with . the requested amount of data. If data 
is to be returned to the TP, RECEIVE_AND_WAIT.MAX_LENGTH is set to the amount 
of data being returned. RECEIVE_AND_WAIT.RETURN_CODE and 
RECEIVE_AND_WAIT.WHAT_RECEIVED are initialized. Also, the FSM_POST undergoes 
state transitions, along with updates to the RCB.POST_CONDITIONS.MAX_LENGTH 
and RCB.POST_CONDITIONS.FILL fields. 


Referenced procedures, FSMs, and data structures: 


PERFORM_RECEIVE_PROCESSING page 5.1-40 
RECEIVE _RM_OR_HS TO PS RECORDS page 5.1-51 
TEST_FOR_POST_SATISFIED page 5.1-60 
FSM_POST page 5.1-68 rcs 
RCB : page A-6 —_ 


TEST POSTING 


Call FSM_POST (page 5.1-68) and pass it a POST_ON_RECEIPT signal. 

Set RCB.POST_CONDITIONS.FILL to the FILL parameter on the RECEIVE_AND_WAIT verb. 

Set RCB.POST_CONDITIONS.MAX_LENGTH to the MAX_LENGTH parameter on the RECEIVE _AND_WAIT verb. 
Call TEST_FOR_POST_SATISFIED(RCB) (page 5.1-60). 

Call PERFORM_RECEIVE_PROCESSING(RCB, RECEIVE_AND_WAIT verb parameters) (page 5.1-40). 


If the state of FSM_POST is PEND_POSTED then a 
Do while the state of FSM_POST is PEND_POSTED. \ 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). See 


Call TEST_FOR_POST_SATISFIED(RCB) (page 5.1-60). 
Call PERFORM_RECEIVE_PROCESSING(RCB, RECEIVE_AND_WAIT verb parameters) (page 5.1-40). 


Set RECEIVE_AND_WAIT.MAX_LENGTH to indicate the amount of data returned to the TP. 
Call FSM_POST (page 5.1-68) and pass it a RECEIVE_IMMEDIATE signal. 


roo 


— “ 
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RECEIVE_RM_OR_HS_TO_PS_RECORDS 


FUNCTION: This procedure receives records from RM and all HS processes and updates the 
appropriate RCB. If SUSPEND_LIST is not empty, this procedure waits until at 
least one record associated with an RCB in SUSPEND_LIST is received. 


All records passed up from HS to PS will be processed at this time. Records 
from HS that do not have RCB associated with them are destroyed or freed by 
the buffer manager. 


CONFIRMED and RSP_TO_REQUEST_TO_SEND are not received in this procedure. When 
a TP is expecting one of these responses, PS does not return control to the TP 
until the response is received in the LU. This processing is done in seperate 
procedures. 


INPUT: SUSPEND_LIST containing RCB_IDs of conversations awaiting incoming records. 


OUTPUT : Records received from HS are stored in the HS_TO_PS_BUFFER_LIST for the appro- 
priate conversation. 


| NOTES: 1. CONVERSATION_FAILURE is the only possible record that can arrive from RM. 
a Other records from RM are received by other procedures when a reply is 
expected from RM. 
This “continuous purging" of records is required by PS for records received 
from HS that do not have an RCB associated with them. 


This “continuous purging" of records is required by PS for records received 
from HS after receipt of a PROTOCOL_VIOLATION or SON record. 


Referenced procedures, FSMs, and data structures: 


CONVERSATION_FAILURE_PROC page 5.1-29 
a PS _PROTOCOL_ERROR page 5.0-20 
; : FSM_CONVERSATION page 5.1-65 

“ FSM_ERROR_OR_FAILURE page 5.1-67 

RCB page A-6 

CONVERSATION_FAILURE page A-21 
CONFIRMED page A-10 
RECEIVE ERROR page A-10 
REQUEST_TO_SEND page A-10 
~RSP_TO_REQUEST_TO_SEND page A-11l 
MU: page A-29 
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RECEIVE_RM_OR_HS_ TO_PS_RECORDS 


Set MORE_RECORDS to TRUE. 
If the SUSPEND_LIST is empty then 
Set SUSPEND_FLAG to NO_SUSPEND. 
Else 
Set SUSPEND _ FLAG to SUSPEND. 


Do while MORE_RECORDS is TRUE: . 
Select based on the value of SUSPEND _ FLAG: 
When SUSPEND 
Find record in RM_ TO_PS_Q or HS_TO_PS_Q and SUSPEND. 
When NO_SUSPEND 
Find record in RM_TO_PS_@ or HS_TO_PS Q@. 


If a record is found then 
If the record is a CONVERSATION_FAILURE then 
Remove the CONVERSATION_FAILURE record from the RM_TO_PS_@Q (see Note 1). 
Find the RCB for the conversation identified by the RCB_ID parameter. 


If the RCB is found then 
Call CONVERSATION_FAILURE_PROC(CONVERSATION_FAILURE) (page 5.1-29). 
Else 
Destroy the CONVERSATION_FAILURE record. 
Else 
Remove the record from the HS_TO_PS Q@. 
Select based on record TYPE: 
When REQUEST_TO_SEND 
Find RCB in the RCB_LIST for the BRACKET_ID secu piael: 
If the RCB is found then | 
Set RCB.RQ_TO_SEND_RCVD to YES. 
Destroy the REQUEST_TO_SEND record. 


When RECEIVE_ERROR 
Find RCB in the RCB_LIST for the BRACKET_ID specified. 
If the RCB is found then 
Call FSM_ERROR_OR_FAILURE( RECEIVE_ERROR, RCB); 
Destroy the RECEIVE_ERROR record. 


When RSP_TO_REQUEST_TO_SEND, CONFIRMED 
Destroy the record (see Note 3). 


When MU 


Find the RCB for the conversation with the BRACKET_ID specified in the MU. 


If the RCB for this conversation is found then 
If the state of FSM_CONVERSATION (page 5.1-65) is RCV_STATE or 
the state of FSM_ERROR_OR_FAILURE (page 5.1-67) is RCVD_ERROR then 
Add the MU to the RCB. HS_TO_PS_BUFFER_LIST. 
Else 
Call buffer manager (FREE BUFFER, buffer address) (Appendix B). 
If the state of FSM_CONVERSATION is END_CONV then 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, X‘'20040000') (page 5.0-20). 
Else (see Note 2) 
Call buffer manager (FREE BUFFER, buffer address) (Appendix B). 


If SUSPEND_FLAG is SUSPEND & the RCB ID for the record just 
processed was 
found in the SUSPEND_LIST then 
Set SUSPEND_FLAG to NO_SUSPEND. 
Else (no record found) 
Set MORE_RECORDS to FALSE. 
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SEND_CONFIRMED_PROC 


SEND_CONFIRMED_PROC 


FUNCTION: This procedure creates a CONFIRMED MU and sends it to HS. 


INPUT: The RCB associated with the half-session to which the CONFIRMED is to be sent 


OUTPUT: A CONFIRMED MU sent to HS 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
MU page A-29 
RCB page A-6 


Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) to create an 
MU for the CONFIRMED; specify the buffer size to be CONFIRMED_MAX_LEN plus the length 
of the MU overhead. 
If a permanent buffer is not available then 
Call buffer manager (GET_BUFFER>, demand, buffer size, no wait) to create an MU for 
the CONFIRMED; specify the buffer size to be CONFIRMED_MAX_LEN plus the length of 
the MU overhead. 


Set MU.HEADER_TYPE to PS_TO_HS. 
Set MU.PS_TO_HS.BRACKET_ID to RCB.BRACKET_ID. 
Set MU.PS_TO_HS.PS_TO_HS_ VARIANT to CONFIRMED. 


Send this CONFIRMED record to HS. 
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5.1-54 


SEND_DATA_BUF FER_MANAGEMENT 


This procedure determines if there is enough data to be sent to HS. 


PS continues to send data to HS until the amount of data remaining to be sent 
is less than or equal to the maximum send RU size, in which case PS stores the 
data in the MU in the RCB until more data is issued by the transaction program 
or the buffer is forced to be sent (e.g., FLUSH, CD) to the partner. If the 
data in the buffer is exactly equal to the maximum send RU size, PS stores the 
data to be sent later. 


Data to be sent to HS, and the RCB corresponding to the resource specified in 
the current TRANSACTION_PGM_VERB 


If enough data has been sent by the transaction program, one or more MUs are 
sent to HS. Otherwise, the data is stored in the MU in the RCB to be sent at 
a later time. Data is copied into the send MU.RU field while the send MU.DCF 
field is incremented to indicate the amount of data present in the send MU. 


After the MU has been completely filled with data, the presence of additional 
data determines if the MU will be sent to HS. If no more data is present, it 
will be held by PS until more data arrives or the direction of the conversa- 
tion forces the MU to be sent. In the latter case, all information (e.g.; 
CONFIRM) can be stored in the RH bits. 


Additional MUs are not requested unless data is present to store in the MU. 
This will prevent utilizing storage for the MU until it is absolutely neces- 
sary. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
CREATE_AND_INIT_LIMITED_MU page 5.1-30 
RCB ; page A-6 
MU page A-29 


If a send MU buffer doesn't exist then 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Else 


If the send MU is full and there is more data to send (see Note 1) then 


Send the MU buffer to HS. 
Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Do while there is more data to send: 
Copy the data into the MU record. 


If the MU is full and there is more data to send then 
Send the MU buffer to HS. 
If there is more data to send (see Note 2) then 


Call CREATE_AND_INIT_LIMITED_MU(RCB, created MU) (page 5.1-30). 


Else (MU not full or no more data) 
Save the MU to send later (see Note 1). 
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SEND_ERROR_DONE_PROC 


FUNCTION: This procedure performs further processing of the SEND_ERROR verb. 


It creates an FMH-7 record and selects the sense data to be inserted in the 
FMH-7 based upon the type of SEND_ERROR, the state of the conversation, and 
whether the outgoing logical record is complete. If the transaction program 
is in send state and has completed the current logical record, sense data 
indicating that no truncation of data has taken place is inserted into the 
FMH-7. If the transaction program is in’ send state and has not completed the 
current logical record, sense data indicating data truncation has occurred is 
inserted into the FMH-7. Finally, if the transaction program is_ in receive 
state, sense data indicating that data sent by the partner transaction program 
is being purged by the half-session is inserted into the FMH-7. 


Sense data X'08890000' and X'08890100' have either of two meanings, depending 
upon whether the transaction program is in send or receive state. 


INPUT: SEND_ERROR verb parameters and the RCB corresponding to the resource specified 
in the SEND_ERROR 


OUTPUT : An FMH-7 is created and stored in the RCB send buffer. If any log data is 
associated with the SEND ERROR, PS creates an Error Log GDS variable (see SNA 
Formats) and stores the GDS variable in the RCB’ send buffer following the 
FMH-7. PS also places the GDS variable (minus the LL and GDS ID fields) in 
the system error log at the local LU. PS returns to the transaction program 
with the RETURN_CODE parameter in the SEND_ERROR set to OK. 


Referenced procedures > FSMs, and data structures: 


HS page 6.0-3 
SEND_DATA_BUF FER_MANAGEMENT page 5.1-54¢ 
FSM_CONVERSATION page 5.1-65 
RCB page A-6 

MU page A-29 


Select based on the following conditions: 


If 


When TYPE parameter of SEND_ERROR verb is PROG and state of FSM_CONVERSATION 
(page 5.1-65) is SEND_STATE 
If data sent by the TP is at a logical record boundary then 
Set SENSE_DATA to X'08890000'. 
Else 
Set SENSE DATA to X'08890001'. 
When TYPE parameter of SEND_ERROR verb is PROG and state of FSM_CONVERSATION 
(page 5.1-65) 1s RCV_STATE, RCVD_CONFIRM, RCVD_CONFIRM_SEND> or RCVD_ CONFIRM_DEALL 
Set SENSE_DATA to X'08890000'. 
When TYPE of - SEND_ERROR is SVC and state of FSM_CONVERSATION (page 5.1-65) is SEND_STATE 
If data sent by the TP is at a logical record boundary then 
Set SENSE_DATA to X'08890100'. 
Else 
Set SENSE_DATA to X'08890101'. 
When TYPE parameter of SEND_ERROR is SVC and state of FSM_CONVERSATION (page 5.1-65) is 
RCV_STATE, RCVD_ CONFIRM, RCVD_CONFIRM_SEND,> or RCVD _CONFIRM_ DEALL 
Set SENSE_DATA to X'08890100". | 
LOG_DATA parameter of SEND_ERROR is not null then 
Create an FMH-7 indicating that LOG_DATA will be present. 
Create Error log GDS variable with the LOG_DATA. 
Call SEND_DATA_BUFFER_MANAGEMENT (Error log GDS variable, RCB) (page 5.1-54). 
(See SNA Formats for Error log GDS format. ) 
Log the error in the system error log. 


Else 


If 


Create an FMH-7 indicating that LOG_DATA will not be present. 


FLUSH verb is not implemented or the FMH-7 is to be flushed immediately 


(as an implementation-dependent option) then 


Send the MU record to HS. 


Set the RETURN_CODE of the SEND_ERROR verb to OK. 
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SEND_ERROR_IN_RECEIVE_STATE 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 


This procedure if invoked when the transaction program issues a SEND_ERROR for 
a conversation that is in the RECEIVE state. Further processing of the 
SEND_ERROR is dependent upon what information, if any» has been received from 
HS and stored in the HS_TO_PS_BUFFER_LIST, as described below. 


SEND_ERROR verb parameters and the RCB corresponding to the resource =pecuiied 
in the SEND_ERROR record 


See below. 


If an MU with the MU.HS_TO_PS.TYPE parameter set to DEALLOCATE has’ been 
received from HS, PS returns to the transaction program after setting the 
RETURN_CODE parameter of the SEND_ERROR to DEALLOCATE_NORMAL. 


If the first MU in the RCB.HS_TO_PS BUFFER_LIST is not a DEALLOCATE, or if the 
RCB.HS_TO_PS_BUFFER_LIST is empty, PS sends a SEND_ERROR record to HS. PS 
then creates an FMH-7 and stores it in the RCB send buffer. 


Referenced procedures, FSMs, and data structures: 


SEND_ERROR_TO_HS_PROC page 5.1-58 
WAIT_FOR_SEND_ERROR_DONE_PROC page 5.1-64¢ 
FSM_CONVERSATION page 5.1-65 
MU page A-29 
RCB page A-6 


Set MU_PTR to the first entry in the RCB.HS_TO_PS_BUFFER_LIST. 


If the end-of-chain type for this conversation is DEALLOCATE_FLUSH then (See Note 1) 
If MU_PTR is not NULL then 
Call buffer manager (FREE_BUFFER, buffer address) ( Appendix B). 
Set the RETURN_CODE of the SEND_ERROR verb to DEALLOCATE_NORMAL. 
Call FSM_CONVERSATION(R, DEALLOCATE_NORMAL_RC, RCB) (page 5.1-65). 
Else (See Note 2) 
Call SEND_ERROR_TO_HS _PROC(RCB) (page 5.1-58). 
Call WAIT_FOR_SEND_ERROR_DONE_PROC(SEND_ERROR verb parameters, RCB) (page 5.1-64). 
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4 SEND_ERROR_IN_SEND_STATE 


FUNCTION: This procedure is invoked when the transaction program issues a SEND_ERROR 
verb for a conversation that is in the SEND state. 


If the state of FSM_ERROR_OR_FAILURE indicates that no RECEIVE_ERROR record 
has been received from HS, any data in PS‘'s send buffer is sent to HS and an 
FMH-7 is created and stored in a newly created MU. 


If the state of FSM_ERROR_OR_FAILURE indicates that a RECEIVE_ERROR record has 
been received from HS, PS sends an MU with the MU.PS TO_HS.TYPE field set to 


PREPARE_TO_RCV_FLUSH to HS. (Any data in the RCB send buffer was purged when 
the RECEIVE_ERROR record was received.) PS then waits for the expected FMH-7 
to arrive. The RETURN_CODE parameter of the SEND_ERROR is set based upon the 
sense data carried in the FMH-7. 


INPUT: SEND_ERROR verb parameters and the RCB corresponding to the resource specified 
in the SEND_ERROR 


“ OUTPUT: Any data in PS'‘'s buffer is sent to HS and an FMH-7 is created and stored in 
a7 the RCB. Send processing begins anew after sending an FMH-7; therefore, the 
send processing fields of the RCB are reset to their initial values. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
RECEIVE_RM_OR_HS_TO_PS_RECORDS page 5.1-51 
SEND_ERROR_DONE_PROC page 5.1-55 
DEQUEUE_FMH7_PROC page 5.1-34 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
- \ RCB page A-6 
= If the state of FSM_ERROR_OR_FAILURE is NO_REQUESTS then 


If a send MU buffer is present then 
Send the MU record to HS. 


Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-65). 
Call SEND_ERROR_DONE_PROC(SEND_ERROR verb parameters, RCB) (page 5.1-55). 
Else (the state is RCVD_ERROR) 
Set MU.PS _TO_HS.TYPE to PREPARE_TO_RCV_FLUSH and send the MU record to HS. 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST containing RCB_ID) (page 5.1-51). 
If the state of FSM_ERROR_OR_ FAILURE is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
a: If the state of FSM_ERROR_OR_FAILURE is CONV_FAILURE_SON then 
Cy Set the RETURN_CODE of the SEND_ERROR verb to RESOURCE_FAILURE_RETRY. 
Else 
Set the RETURN_CODE of the SEND_ERROR verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else 
Call DEQUEUE_FMH7_PROC(SEND_ERROR verb parameters, RCB) (page 5.1-34). 
Set the RCB send processing fields to their initial values. 
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SEND_ERROR_TO_HS_PROC | (~ 


FUNCTION: This procedure creates a SEND_ERROR MU and sends it to HS. 


INPUT: The RCB associated with the HS to which the SEND_ERROR MU is to be sent 


OUTPUT : A SEND_ERROR is created to be sent to HS 


Referenced procedures, FSMs» and data structures: 


HS page 6.0-3 
MU page A-29 
RCB page A-6 


Call buffer manager (GET_BUFFER, buffer size) to create an MU for the SEND_ERROR; 
specify the buffer size to be SEND_ERROR_MAX_LEN plus the length of the MU 
overhead. 


Set MU.HEADER_TYPE to PS_TO_HS. 


Set MU.PS_TO_HS.BRACKET_ID to RCB.BRACKET_ID. 7 : a 
Set MU.PS_TO_HS.PS_TO_HS_VARIANT to SEND_ERROR. te 
Send this SEND_ERROR record to HS. 
SEND_REQUEST_TO_SEND_PROC 

Bes \ 


FUNCTION: This procedure creates an MU containing a REQUEST_TO_SEND and sends it to HS. ( 


INPUT: The RCB associated with the half-session to which the REQUEST_TO_SEND is to be 
sent 
OUTPUT : A REQUEST_TO_SEND is created to be sent to HS. 


Referenced procedures, FSMs» and data structures: 


HS page 6.0-3 
MU page A-29 
RCB page A-6 _ 
| a 
Call buffer manager (GET_BUFFER, buffer size) to create an MU for the REQUEST_TO_SEND; ( 
specify the buffer size to be REQUEST_TO_SEND_MAX_LEN plus the length of the MU See 
overhead. 
Set MU.HEADER_TYPE to PS_TO_HS. 
Set MU.PS TO_HS.BRACKET_ID to RCB.BRACKET_ID. 
Set MU.PS TO_HS.PS_TO_HS VARIANT to REQUEST_TO_SEND. 
Send this REQUEST_TO_SEND record to HS. 
a 
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_ SET_FMH7_RC 


FUNCTION: This procedure sets the RETURN_CODE parameter of the passed transaction pro- 
gram verb based upon the passed | sense data. 


INPUT: The RCB corresponding to the resource to which the FMH-7 applies, the received 
FMH-7 sense data, and the transaction program verb parameters currently being 
processed 


OUTPUT: The RETURN_CODE parameter of the verb is set, based upon the sense data passed 
from the received FMH-7. 


NOTE : When the sense data in the FMH-7 indicates an allocation error, a deallocation 
notification is expected. If this expected notification is not received, a 
protocol violation has occurred. The procedure GET_DEALLOCATE_FROM_HS per- 
forms the appropriate processing» which includes placing the conversation in 
END_CONV state. 


| C Referenced procedures, FSMs, and data structures: 
PS PROTOCOL_ERROR page 5.0-20 
FSM_CONVERSATION - page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


Select based on the sense data in FMH-7: 
When ALLOCATION_ERROR code 
Get the DEALLOCATE from the RCB.HS_TO_PS BUFFER_LIST. 
If the state of FSM_CONVERSATION is not END_CONV then 
Set RETURN CODE parameter of the verb to the corresponding value (see SNA Formats to 
find the value corresponding to a given sense data). 
| Call FSM_CONVERSATION(R, ALLOCATION_ERROR, RCB) (page 5.1-65). 
Bg. When RESOURCE _FAILURE_NO_RETRY 
C Set RETURN_CODE parameter of the TP verb to RESOURCE_FAILURE_NO_RETRY. 
Bs Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When PROG_ERROR_NO_TRUNC or PROG_ERROR_PURGING 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is RCVD_ERROR then 
. Set RETURN_CODE parameter of the verb to PROG_ERROR_PURGING. 


Else — 

Set RETURN_CODE parameter of the verb to PROG_ERROR_NO_TRUNC. 
Call FSM_CONVERSATION(R, PROGRAM_ERROR_RC, RCB) (page 5.1-65). 

When PROG_ERROR_TRUNC 
Set RETURN_CODE parameter of the verb to PROG_ERROR_TRUNC. 
Call FSM_CONVERSATION(R, PROGRAM_ERROR_RC, RCB) (page 5.1-65). 
iy When SVC_ERROR_NO_TRUNC or SVC_ERROR_PURGING 
é If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is RCVD_ERROR then 
Set RETURN_CODE parameter of the verb to SVC_ERROR_PURGING. 


Else 
Set RETURN_CODE parameter of the verb to SVC_ERROR_NO_TRUNC. 
Call FSM_CONVERSATION(R, SERVICE_ERROR_RC» RCB) (page 5.1-65). 
When SVC_ERROR_TRUNC 
Set RETURN_CODE parameter of the verb to SVC_ERROR_TRUNC. 
Call FSM_CONVERSATION(R, SERVICE_ERROR_RC, RCB) (page 5.1-65). 
When DEALLOCATE_ABEND 
Set RETURN_CODE parameter of the verb to DEALLOCATE_ABEND_PROG, DEALLOCATE_ABEND_SVC, 
DEALLOCATE_ABEND_TIMER, or to DEALLOCATE_ABEND_RC 
as shown in SNA Formats under X'0864' Sense Code. 
Call FSM_CONVERSATION(R, DEALLOCATE_ABEND_RC, RCB). 
Otherwise (as an implementation-dependent option): 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, FMH-7 sense data) (page 5.0-20). 
Set RETURN_CODE parameter to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
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TEST_FOR_POST_SATISFIED 


FUNCTION: 


INPUT : 


OUTPUT: 


This procedure tests whether the post conditions specified in the RCB have 
been satisfied. 


The RCB corresponding to the resource to be tested 


The state of FSM_POST is set to POSTED if the post conditions are satisfied. 


Referenced procedures, FSMs, and data structures: 


FSM_POST 
MU 


Testing for posting involves examining the data (logical records) in 
the received MUs to see if the data will satisfy the conditions speci- 
fied in the RECEIVE_* verb. Receipt of any of the following can cause 
posting to be satisfied: 

End-of-Chain type received 


Conversation Failure record from RM--Session-Outage Notification 
(SON ) 


Conversation Failure record from RM--Protocol Violation 

FMH-7 

Complete logical record with FILL=LL 

Remainder of partial returned logical record with FILL=LL 

Enough data in the buffer to satisfy the FILL=BUFFER condition 

An invalid LL in the received data 
During the testing process, the data in the received MUs is traversed 
one logical record at a time until any one of the conditions listed 
above is recognized. Information on the location in the MU, location 


in the logical record, and number of bytes remaining in the current 
logical record is continually updated as the data is examined. 


A logical record is preceded by a 2-byte length field. These length 
bytes are not passed to the transaction program until both bytes are 
present in the receive buffer. If only the first byte is in the 
receive buffer, it 1s saved until the second byte arrives. With both 
bytes present, the length field is checked for validity. While wait- 
ing for the second length byte to arrive, a number of conditions can 
validly truncate the logical record, i.e., receipt of: 


e §©Conversation Failure--Session-Outage Notification (SON) 
® Conversation Failure--Protocol Violation 


bd FMH-7 
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WAIT_FOR_CONFIRMED_PROC 


FUNCTION: This procedure is invoked after an MU indicating CONFIRM has’ been sent to HS 
and a CONFIRMED record is expected in reply. 


HS can send other records to PS while PS is waiting for the expected CONFIRMED 
record. Appropriate action is taken, depending upon the record received (see 
below). 


The transaction program verb that caused the CONFIRM indicator to be sent to 
HS, and the RCB corresponding to the resource specified in the transaction 
program verb 


OUTPUT: See below. 


NOTES: . If a REQUEST_TO_SEND record is received, PS stores that information in the RCB 
to be relayed to the transaction program at a later time, and continues to 
wait for the expected CONFIRMED record. 


If a RECEIVE_ERROR record is received, PS waits for the FMH-7 corresponding to 
the RECEIVE_ERROR to arrive from HS. The RETURN_CODE of the passed trans- 
action program verb is set based upon the sense data carried in the FMH-7. 
Control is then returned to the transaction program. 


If the expected CONFIRMED is received, PS returns control to the transaction 
program. 


If the transaction program has issued a DEALLOCATE (TYPE = SYNC_LEVEL) and the 
SYNC_LEVEL of the conversation is CONFIRM, FSM_CONVERSATION will be in the 
PEND_DEALL state when the CONFIRMED record arrives. The CONFIRMED record 
causes the requested deallocation to be completed. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-8 
CONVERSATION_FAILURE_PROC page 5.1-29 
DEQUEUE_FMH7_PROC page 5.1-34 
END_CONVERSATION_PROC page 5.1-34 
PS _PROTOCOL_ERROR page 5.0-20 
RECEIVE_RM_OR_HS_TO_PS_RECORDS page 5.1-51 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
CONFIRMED page A-10 
CONVERSATION_FAILURE page A-21 
RECEIVE_ERROR page A-10 
REQUEST_TO_SEND page A-10 
RCB page A-6 


Do while CONFIRMED response has not been received: 
Get the first record for this conversation. 
Select based on the type of the record: 
When CONVERSATION _FAILURE then 
Call CONVERSATION_FAILURE_PROC with record (see page 5.1-29). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_RETRY. 
Else 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Response condition is satisfied. 
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When REQUEST_TO_SEND (see Note 1) 
Set RCB.RQ_TO_SEND_RCVD to YES. 
Destroy the REQUEST_TO_SEND record. 
When RECEIVE_ERROR (see Note 2) 
Call FSM_ERROR_OR_FAILURE(RECEIVE_ERROR, RCB) (page 5.1-67). | 
Call RECEIVE_RM_OR_HS_TO_PS_RECORDS(SUSPEND_LIST contains RCB ID) (page 5.1-38). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-67) is CONV_FAILURE_SON then 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_RETRY. 
Else 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Else 
Call DEQUEUE_FMH7_PROC(CONFIRM verb parameters, RCB) (page 5.1-34). 
Response condition is satisfied. 
Destroy the RECEIVE_ERROR record. 
When CONFIRMED (see Note 3) 
Set RETURN_CODE parameter of the verb to OK. 
If state of FSM_CONVERSATION is PEND_DEALL then (see Note 4) 
Call FSM_CONVERSATION(R, DEALLOCATION_INDICATOR;, RCB) (page 5.1-65). 


fo 


Call END_CONVERSATION_PROC(RCB) (page 5.1-34). jee 
Response condition is satisfied. LL 
Destroy the CONFIRMED record. ci 

Otherwise 


Call PS_PROTOCOL_ERROR(RCB.HS_ID, X'10010000') (page 5.0-20). 
Call FSM_CONVERSATION(R, CONFIRMED, RCB) (page 5.1-65). 


WAIT_FOR_RM_REPLY 


FUNCTION: This procedure waits for an expected reply from the resources manager. 


INPUT: At least one record from the RM_TO_PS_Q 


OUTPUT: A record received from the resources manager 


NOTES: - CONVERSATION_FAILURE is the only record that can arrive unexpectedly from the 
resources manager. 


Any record from the resources manager, other than CONVERSATION_FAILURE > must 
be the expected reply. No more than one reply from the resources manager is 
outstanding at any time. 


Referenced procedures, FSMs, and data structures: 


RM ° page 3-19 
CONVERSATION_FAILURE_PROC page 5.1-29 
CONVERSATION_FAILURE page A-21 


Do while record from RM has not arrived: 
Wait for a record to arrived from RM. 
If the record from RM is a CONVERSATION_FAILURE then (see Note 1) 
Call CONVERSATION_FAILURE_PROC(CONVERSATION_FAILURE record) (page 5.1-29). 
Else (see Note 2) 
Record received from RM, return the record. 
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WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 


FUNCTION: 


INPUT: 


This procedure is invoked after PS has issued a REQUEST_TO_SEND to HS. The 
next record that is expected from HS is RSP_TO_REQUEST_TO_SEND. 


HS can send records to PS while PS is waiting for the expected 
RSP_TO_REQUEST_TO_SEND record. Appropriate action is taken, depending upon 
the record received (see below). 


The RCB corresponding to the conversation for which the REQUEST_TO_SEND was 
issued is passed as a parameter to this procedure; HS_TO_PS_RECORDs are 
received from HS. 


See below. 


If a REQUEST_TO_SEND is received, PS stores that information in the RCB and 
continues to wait for the RSP_TO_REQUEST_TO_SEND. 


Since REQUEST_TO_SEND does not support the RESOURCE_FAILURE return code, if a 
RECEIVE_ERROR is received, the information is stored in FSM_ERROR_OR_FAILURE 
to be presented to the transaction program when it issues a verb that does 
support the RESOURCE_FAILURE return code. 


When RSP_TO_REQUEST_TO_SEND is received, control is returned to the trans- 
action program. 


Any data received from HS before the RSP_TO_REQUEST_TO_SEND arrives is stored 
in the HS_TO_PS_BUFFER_LIST. PS continues to wait for the 
RSP_TO_REQUEST_TO SEND. However, if an MU with TYPE field set to DEALLO- 
CATE_FLUSH is received, the RSP_TO_REQUEST_TO_SEND will not be received by PS; 
so PS returns control to the transaction program. 


_ Referenced procedures, FSMs, and data structures: 


CONVERSATION_FAILURE_PROC page 5.1-29 
PS _PROTOCOL_ERROR page 5.0-20 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
COVERSATION_FAILURE, see CONVERSATION_FAILURE page A-21 
MU — page A-29 
REQUEST_TO_SEND page A-10 
RECEIVE_ERROR, see RSP_TO_REQUEST_TO_SEND page A-1l 
RSP_TO_REQUEST_TO_SEND, see RECEIVE _ERROR page A-10 
RCB page A-6 


Do while the 


response has not been received (response condition not satisfied): 


Get the first record for this conversation. 
Select based on the type of the record: 
When CONVERSATION_FAILURE then 


Call 


CONVERSATION_FAILURE_PROC with record (page 5.1-29). 


Response condition is satisfied. 
When REQUEST_TO_SEND (see Note 1) 

Set RCB.RQ_TO_SEND_RCVD to YES. 

Destroy the REQUEST_TO_SEND record. 
When RECEIVE_ERROR (see Note 2) 


Call 


FSM_ERROR_OR_FAILURE( RECEIVE ERROR, RCB) (see page 5.1-67) 


Destroy the RECEIVE_ERROR record. 

When RSP_TO_REQUEST_TO_SEND (see Note 3) 
Response condition is satisfied. 
Destroy the RSP_TO_REQUEST_TO_SEND record. 


When MU 


(see Note 4) 


Add the MU to the RCB.HS TO_PS.BUFFER_LIST. 
Set MU to the last entry of HS_TO_PS_BUFFER_LIST. 
If the end-of-chain type has been received and is DEALLOCATE_FLUSH then 
Response condition is satisfied. 
Otherwise 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, FMH-7 Sense Data) (page 5.0-20). 
Call FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-65). 
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WAIT_FOR_SEND_ERROR_DONE_PROC 


FUNCTION: This procedure is invoked after a SEND_ERROR MU has been sent to HS. The 
SEND_ERROR was sent to HS as a result of the transaction program issuing a 
SEND_ERROR or DEALLOCATE (TYPE = ABEND_PROG, ABEND_SVC, or ABEND_TIMER) for a 
conversation that is in receive state. 


The procedure calls GET_END_CHAIN_FROM_HS (page 5.1-36) to await the arrival 
from HS of a record indicating the end-of-chain type. Appropriate action is 
taken depending on the type of record received. 


INPUT: Transaction program verb parameters and the RCB corresponding to the resource 
specified in the verb 


OUTPUT: See below. eo 


NOTES: 1. If the record received from HS is an MU with the MU.HS_TO_PS.TYPE field set to ge 
DEALLOCATE_FLUSH, the conversation is deallocated and the return code of the 
verb is set to indicate the deallocation. 


2. If the record received from HS is an MU with the MU.HS_TO_PS.TYPE field set to 
DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, or PREPARE_TO_RCV_FLUSH, 
the processing of the verb is continued. 


3. FSM_ERROR_OR_FAILURE is reset to NO_REQUESTS because, in certain SEND_ERROR 
race cases, a RCVD_ERROR condition is not reported to the transaction program. 
Normally, FSM_ERROR_OR_FAILURE is reset to NO_REQUESTS by SET_FMH7_RC (page 
5.1-59) when the error is reported to the TP. PR 


Referenced procedures, FSMs, and data structures: 


GET_END_CHAIN_FROM_HS page 5.1-36 
SEND_ERROR_DONE_PROC page 5.1-55 
COMPLETE_DEALLOCATE_ABEND_PROC | page 5.1-29 
FSM_CONVERSATION page 5.1-65 
FSM_ERROR_OR_FAILURE page 5.1-67 
RCB page A-6 


Call GET_END_CHAIN_FROM_HS(RCB) (page 5.1-36). 


Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-67): a 
When CONV_FAILURE_SON ( 
Set the RETURN_CODE of the verb to RESOURCE_FAILURE_RETRY. Sa? 


Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
When CONV_FAILURE_PROTOCOL_ERROR 
Set the RETURN_CODE of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R» RESOURCE_FAILURE_RC, RCB) (page 5.1-65). 
Otherwise 
Select based on the following conditions: 
When end-of-chain type is DEALLOCATE_FLUSH (see Note 1) and the verb is SEND_ERROR 
Set the RETURN_CODE of the verb to DEALLOCATE_NORMAL. 
Call FSM_CONVERSATION(R, DEALLOCATE_NORMAL_RC, RCB) (page 5.1-65). 
When end-of-chain type is DEALLOCATE_FLUSH and the verb is DEALLOCATE 
Set the RETURN_CODE of the verb to OK. : 
When end-of-chain type is DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, 
or PREPARE_TO_RCV_FLUSH (see Note 2) and the verb is SEND ERROR 
Purge the end-of-chain type received on this conversation. 
Call SEND_ERROR_DONE_PROC(SEND_ERROR verb parameters, RCB) 
(page 5.1-55). 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-65). . 
When end-of-chain type is DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, 
or PREPARE_TO_RCV_FLUSH, and the verb is DEALLOCATE ’ 
Call COMPLETE_DEALLOCATE_ABEND_PROC(DEALLOCATE verb parameters, RCB) C 
(page 5.1-29). » 
Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it a RESET signal (see Note 3). 
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FINITE-STATE MACHINES 


Sted 


FSM_CONVERSATION 


FUNCTION: 


This finite-state machine maintains the status of a conversation resource. 
The states have the following meanings: 


RESET = conversation initial state, the program can allocate it 


SEND_STATE = the program can send data, request confirmation, or request 
sync point 


RCV_STATE = receive, the program can receive information from the remote 
program 


RCVD_CONFIRM = received confirm, PS received the confirm indicator from 
the HS 


RCVD_CONFIRM_SEND = received confirm send, PS received the confirm send 
indicator from HS 


RCVD_CONFIRM_DEALL = received confirm deallocate, PS received the confirm 
deallocate from HS 


PREP_TO_RCV_DEFER = prepare to receive defer, the program issued a PRE- 
PARE_TO_RECEIVE verb with SYNCPT 


DEALL_DEFER = deallocate defer, the program issued DEALLOCATE verb with 
SYNCPT 


PEND_DEALL = pending deallocate, the program issued DEALLOCATE verb with 
CONFIRM 


The inputs are marked with S if they result from an action of the local trans- 
action program and with R if they result from a record sent to PS by HS. The 


RCB is passed to provide the information needed to perform the state transi- 
tion of the FSM_CONVERSATION and its output function. 


PEND_DEALL is an intermediate state. PS does not return control to the trans- 


action program when the conversation is in this state. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_ERROR_OR_FAILURE page 5.1-67 
MU page A-29 
RCB page A-6 
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RESOURCE_FAILURE_RC 
ALLOCATION_ERROR_RC 


DEALLOCATE_FLUSH 


DEALLOCATE_CONFIRM 
DEALLOCATE_DEFER 
S, DEALLOCATE_ABEND 
S, DEALLOCATE_LOCAL 


> 
R, DEALLOCATED_IND / 
S, GET_ATTRIBUTES / 


OUTPUT FUNCTION 
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uae Call FSM_ERROR_OR_FAILURE (page 5.1-67) and pass it a RESET signal. 


/ 


/ 
/ 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
: 
> 
> 
> 
7 
7 
7 
7 
3(B) [7 : 
3(B) |7 (" i 
7 
/ 
/ 
7 
> 
> 
> 
> 
1 


> > / 
> > / 
> > / 
1 1 / 
> > / 
Be ed 


A / 
/ / 
> > 
> > 
> > 
> > 
> > 
> > 
2 2 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
7 / 
/ / 
/ / 
7 / 
on co 
7 A 
/ / 
/ 7 
/ / 
7 / 
/ / 
> > 
> > 
> > 
1 1 
> > 


/ 
/ 
> 
> 
> 
> 
> 
> 
2 
> 
> 
> 
> 
> 
> 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
> 
> 
> 
1 
> 


ak Pi PP ee | 


> 
> 
> 
1 
> 


SNA LU 6.2 Reference: Peer Protocols 


C FSM_ERROR_OR_FAILURE 


FSM_ERROR_OR_FAILURE 


FUNCTION: This finite-state machine remembers if any error or failure MU records (either 
from HS to PS or RM to PS) have been received by PS. This Knowledge is main- 
tained until the information reflected by the records can be passed to the 
transaction program. The meanings of the states are as follows: 


_@ NO_REQUESTS = the initial state of the FSM 


RCVD_ERROR = a RECEIVE_ERROR was received 


CONV_FAILURE_PROTOCOL_ERROR = a conversation protocol error record was 


received 


CONV_FAILURE_SON = a session outage notification for the conversation was 


received 


The inputs are the error and failure records from the HS and RM. 


C3 Referenced procedures, FSMs, and data structures: 
RCB 
MU 


STATE NAMES---->| NO 
REQUESTS _ 
INPUTS STATE NUMBERS-->| 01 
SIGNAL(CONV_FAIL_PROTOCOL ) 3 
S SIGNAL( CONV_FAIL_SON) G 


= RECELVE_ERROR 


SIGNALCRESET ) 


OUTPUT FUNCTION 
CODE 


page A-6 
page A-29 


CONV CONV 
FAILURE FAILURE 
PROTOCOL 


If the send MU buffer exists then 
- Set the values in the send MU to their initial values (purge the data in the MU) 
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FSM_POST 
FSM_POST | a 
\ 


FUNCTION: This finite-state machine maintains the posting status of a conversation. The 
meanings of the states are as follows: 


e RESET = the initial state of the FSM 


e PEND_POSTED = state after the FSM- received a POST_ON_RECEIPT input 


e POSTED = state to show that post conditions were satisfied 


1. If POST_ON_RECEIPT is issued after posting has already been activated (1.e., a 
prior POST_ON_RECEIPT has been issued), the post conditions used to test for 
post satisfied are reinitialized to those carried in the most recent 
POST_ON_RECEIPT. 


RECEIVE_IMMEDIATE resets posting. If posting is activated and the conversa- 
tion has been posted, this FSM is reset. If posting 1s activated and the con- 
versation has not been posted, posting is canceled and this FSM is reset. 


The initial state of this FSM is RESET. 


STATE NAMES----> : POSTED 
INPUTS STATE NUMBERS--> | 03 


POST_ON_RECEIPT 2 [Note 1] 
TEST 1 
WAIT 1 
RECEIVE_IMMEDIATE 1 [Note 2] 
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GENERAL DESCRIPTION 


A transaction program (TP) requests LU serv- 
ices by issuing verbs. The verbs request 
several different Kinds of services, and are 
therefore divided into several different cat- 
egories (see SNA Transaction Programmer's 
Reference Manual for LU Type 6.2 for a com- 
— plete description of the verbs). Each 
; verb-processing component of PS processes the 
: verbs of one specific category. Presentation 
services for mapped conversations (PS.MC) is 
the PS component that processes the verbs of 
the mapped conversation category (basic con- 
versation verbs are processed by "Chapter 
5.1. Presentation Services--Conversation 
Verbs" in Chapter 5.1). 


PS.MC FUNCTIONS 


* 

| 

4 The primary function of PS.MC is reformatting 
the data contained in the DATA parameters of 
the MC_SEND_DATA and  MC_RECEIVE_AND_WAIT 
verbs. Its subsidiary functions include the 
processing of errors related to this refor- 
matting, and the translation of mapped con- 
versation verbs into basic conversation verbs 
in support of services unrelated to format- 


ting. 
_ When the TP issues a mapped conversation 
a verb, PS.MC processes the verb and performs 
, the services that it requests. PS.MC does 


not, however, perform all the services 
requested by every mapped conversation verb. 
PS.MC performs only those services related to 
data formatting. If the verb requests addi- 
tional conversation services that are not 
related to data formatting, then PS.MC, by 
issuing one or more basic conversation verbs, 
causes PS.CONV to perform those services. 


In general, the TP is faced with two format- 
ting problems. The data format that it pre- 
fers for computational processing differs 
from the formats in which data is presented 
to (or by): 


S Local end users and resources 


@ Half-sessions (for communication with 
remote end users and resources). 


C | PS.MC solves the formatting problem for local 
end users and resources by routing all data 
presented to (or by) them through a component 

called "the Mapper" (UPM_MAPPER on page 


The mapped conversation verbs are issued on 
mapped conversations, and basic conversation 
verbs are issued on basic. conversations. 
Both the basic and the mapped conversation 
verbs request communication services for 
transaction programs. A mapped conversation, 
however, is easier for the communicating 
transaction programs to use because it also 
provides data formatting services that the 
programs would have to perform for themselves 
if they were using a basic conversation. 


5.2-46), which transforms data into (when 
receiving) or out of (when sending) formats 
preferred by end users. For communication 
with conversation partners, TP data must be 
made to conform to the format that SNA 
defines for the conversation data stream. On 
basic conversations, the conversing TPs must 
perform this formatting for themselves, but 
on mapped conversations, PS.MC adds (when 
sending) and strips (when receiving) the 
data-stream details required by the format. 


The functions that PS.MC performs for the 
transaction program are summarized below: 


e =§=§=6Adding and stripping conversation 
data-stream formatting details (see "Con- 
versation Data Stream Formatting" on page 
5.2-5) 


e Data mapping (see “Data Mapping and the 
' Mapper" on page 5.2-8) 


e Allowing function management headers 
(FMHs) to flow on the mapped conversation 
(see "FM Header Data" on page 5.2-7) 


e Detecting service errors committed by 
the partner transaction program (see 
“Service Errors Detected in Received 
Data" on page 5.2-14) 


e Processing service errors committed by 
the local transaction program = and 
detected by the partner LU (see “Process- 
ing of a Service Error Detected by Part- 
ner LU" on page 5.2-17). 
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See "Chapter 5.1. Presentation Services--Conversation Verbs" 
See "Chapter 5.3. Presentation Services--Sync Point Services Verbs" 
3 See "Chapter 5.4. Presentation Services--Control-Operator Verbs" 


Note: A dashed line denotes a synchronous (or call/return) protocol boundary between PS components» 
while a solid line denotes an asynchronous (or send/receive) protocol boundary. 


Figure 5.2-1. Overview of Presentation Services, Emphasizing Presentation Services for Mapped 
Conversations 


COMPONENT INTERACTIONS 


C_ 


In terms of layering> non-basic-conversation sublayer of presentation services. PS.MC 


verb-processing components (such as PS.MC) communicates primarily with the TP and 
reside below the TP but above the PS.CONV PS.CONV. Figure 5.2-2 on page 5.2-3 illus- 
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Note: 


Figure 
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Data Flow 
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Resources Manager 


Data Flow 
Control 


See "Component Interactions" on page 5.2-2 for an explanation of the flows 


shown in this figure. 


5.2-2. 


trates the flow of processing. PS.MC accepts 
issuances of mapped conversation verbs from 


the TP, but issues basic conversation verbs 
to PS.CONV. Whenever a verb is issued by any 
component (for example, the TP), 


PS.VERB_ROUTER (Chapter 5.0) gains control 
and is responsible for routing the verb to 
the appropriate PS component for processing. 


When the TP issues a mapped conversation verb 
(flow 1 in Figure 5.2-2), the verb is 
inspected by PS.VERB_ROUTER. PS.VERB_ROUTER 
determines that the verb is a mapped conver- 
sation verb and calls PS.MC, passing to it 
the received verb (flow 2). PS.MC may issue 


Chapter 5.2. 


Presentation Services--Mapped Conversation Verbs 


PS.MC's Use of the Basic Conversation Protocol Boundary 


a basic conversation verb during its process- 
ing of the mapped conversation verb. If it 
does, then it calls PS.CONV and passes the 
verb to it (flow 3). PS.CONV processes the 
basic conversation verb, after which control 
returns along the same path to PS.MC. 


A transaction program may support only mapped 


conversations or only basic conversations. 
Alternatively, it may support both types of 
conversation. In the latter case, the trans- 


action program may have mapped conversations 
and basic conversations allocated concurrent- 
ly. The PS.VERB_ROUTER requires the TP to 
issue only mapped conversation verbs. on 


5.2-3 


mapped conversations and only basic conversa- 
tion verbs on basic conversations. However, 


PS.MC DATA BASE STRUCTURE 


52-4 


In order to perform its’ functions, PS 
requires information about the transaction 
program that it is serving and about the 
resources currently allocated to that trans- 
action program. This information, which is 
described in "PS.CONV Data Base Structure” on 
page 5.1-1 , is stored in lists of control 
blocks in the LU (see Appendix A for complete 
definitions of the lists and of the entities 
that may be found in the lists). Some of the 
fields in these control blocks are especially 
important to  PS.MC. Those fields are 
described below. 


TRANSACTION CONTROL BLOCK (TCB) 


Each transaction control block (TCB) contains 
information about one execution instance of a 
transaction program. PS.MC identifies the 
TCB describing the particular’ transaction 
program instance that it is serving by means 
of the TCB_ID that RM passed to PS when the 
transaction program instance was created. 
The TCB fields used by PS.MC contain such 
information as the name of the transaction 
program that PS is serving and the LU_ID of 
the LU in which the PS resides. 


LU CONTROL BLOCK (LUCB) 


PS.MC accesses the appropriate LUCB using a 
unique LU_ID, which is stored in the TCB to 
which PS.MC has access. The LUCB fields in 
which PS.MC is particularly interested con- 
tain information about whether the LU = sup- 
ports various mapped conversation options, 
such as handling of FM header data. 


Transaction Program Control Block (TPCB) 


Each LUCB also contains a pointer to a list 
of transaction program control blocks 
(TPCBs). For a given LU, the list contains a 
TPCB for each transaction program that is 
capable of running at the LU. The informa- 
tion contained in a TPCB includes the name of 
the transaction program and whether it sup- 
ports various optional features. PS.MC, in 
particular, is interested in whether or not 
the TP supports mapped conversations. 


RESOURCE CONTROL BLOCK (RCB} 
PS.MC also requires information about all the 


mapped conversations allocated to the trans- 
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PS.VERB_ROUTER allows PS.MC to issue basic 
conversation verbs on a mapped conversation. 


action program. This information is found in 
the resource control block (RCB), one for 
each resource associated with any transaction 
programs running at an LU. As in the case of 
the TCB, PS.MC is interested in only those 
RCBs containing information about mapped con- 
versation resources allocated to its own 
transaction program. 
mation about resources that are not mapped 
conversations or are allocated to other 
transaction programs. 


PS.MC accesses an RCB by means of the RCB_ID. 
The transaction program supplies an RCB_ID in 
the RESOURCE parameter of a verb in order to 
indicate the particular conversation resource 
on which the verb is being issued. Whenever 
@ new resource is allocated, the resources 
manager ("Chapter 3. LU Resources Manager" in 
Chapter 3) creates a new RCB_ID and returns 
it to the transaction program in the RESOURCE 
parameter of the MC_ALLOCATE verb. The RCB 
also contains the TCB_ID of the transaction 
program instance that has allocated the 
resource. RCB information is initialized 
when the conversation is allocated. 


The following RCB_ fields 
important to PS.MC. 


are especially 


MC_MAX_SEND_SIZE contains the length of the 
longest logical record that can be 
sent on the conversation, and is 
used to segment outgoing data (see 
"Construction of GDS Variables" on 
page 5.2-5). 


«MAPPER_SAVE_AREA contains information used in 


data mapping, such as the currently 
effective map names (see "Map 
Names" on page 5.2-8). The mapper 
may also, however, use data stored 
in this area to perform 
implementation-defined (as opposed 
to SNA-map-name-defined) data map- 
ping. The mapper also uses this 
area to save any error data or 
indicators of events that occurred 
during data mapping. 


MC_RECEIVE_BUFFER contains information = that 
- has arrived from aé_ conversation 
partner but that has not yet been 
received by the transaction pro- 
gram. 
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CONVERSATION DATA STREAM FORMATTING 


When a transaction program sends data on a 
basic conversation, it must ensure that that 
data conforms to the format of the conversa- 
tion data stream. A transaction program that 
allocates a mapped conversation, however, 
does not need to perform this task, because 
PS.MC assumes responsibility for editing the 
data to make it conform to the format of the 
conversation data stream. Transaction pro- 
grams communicating over a mapped conversa- 
tion may supply their data in any format. 


All data flowing on any conversation is for- 
matted into logical records. A logical 
record consists of a 2-byte logical record 
length field (LL) followed by a data field. 
A transaction program sending data over a 
basic conversation must take care to include 
the LL fields in its data, and to complete 
the logical record that it is sending before 
leaving SEND state. 


A TP sending data over a mapped conversation 
has neither of these concerns, because PS.MC 
computes and inserts the LLs for it. The TP 
simply supplies the data in the DATA parame- 
ter of MC_SEND_DATA. PS.MC then maps the 
data and formats the mapped data into one or 
more complete logical records. 


CONSTRUCTION OF GDS VARIABLES 


PS.MC formats all data flowing on a mapped 
conversation into general data stream (GDS) 
variables (see Figure 5.2-3). A GDS variable 
consists of one or more complete logical 
records. The data field of the first logical 
record in a GDS variable begins with a 2-byte 
GDS ID that identifies the type of informa- 
tion contained in the variable. The informa- 
tion itself begins in the third byte of the 
data field of the first logical record, and 
continues throughout the data fields of the 
variable's remaining logical records, which 
do not contain the GDS ID. 


GDS Variable 
(Consisting of 1 Logical Record) 


ee 


Logical Record 


Figure 5.2-3. GDS Variables and Logical 
Records 


The following types of GDS variables flow on 
mapped conversations: 


Map Name 
Application Data 
User Control Data 
Error Data 

Error Log 

Null Data 


(See SNA Formats for descriptions of all the 
valid types of GDS variables and their GDS ID 
values. ) 


Map Name GDS variables are generated from the 
MAP_NAME parameter of MC_SEND_DATA (see "Map 
Names" on page 5.2-8 for details). Applica- 
tion Data and User Control Data GDS variables 
(collectively called data GDS variables) are 
generated from data supplied via the DATA 
parameter of MC_SEND_DATA. If this verb is 
issued with FMH_DATA(YES), the data is put 
into a User Control Data GDS variable; other- 
wise, it is put into an Application Data GDS 
variable. Error Data GDS variables are gen- 
erated when the TP issues MC_SEND_ERROR or 
when PS detects an error (see "Mapped Conver- 
sation Errors" on page 5.2-12 for details). 


Null Data GDS variables are optionally gener- 
ated when the TP, after entering SEND state, 
leaves SEND state without sending any data. 
(Instead of issuing MC_SEND_DATA, the’ TP 
issues MC_CONFIRM, MC_PREPARE_TO_RECEIVE, or 
some other verb that removes the TP from SEND 
state.) The partner must be notified of 
this change in state. The RH that conveys 
this state-change notification (CD for 
MC_PREPARE_TO_RECEIVE , or RQD2 for 
MC_CONFIRM}) can flow to the partner by means 
of a null-data FMD request, a LUSTAT request, 
or a Null Data GDS variable created by PS.MC. 
An Application Data GDS variable with a null 
data field cannot be used for this purpose, 
because that would erroneously indicate that 
the TP had issued MC_SEND_DATA~ with 
LENGTH(O), when the TP has not’ issued 
MC_SEND_DATA at all. 


GDS Variables with Multiple Logical Records 


Only data GDS variables may consist of multi- 
ple logical records; Error and Map Name GDS 
variables each consist of a single logical 
record. Whether a data GDS variable will 
have more than one logical record is deter- 
mined by the value of MC_MAX_SEND_SIZE, which 
is the length of the longest logical record 
that may be sent on the mapped conversation. 
MC_MAX_SEND_SIZE may vary from mapped conver- 
sation to mapped conversation, or it may be 
the same for all mapped conversations. 
MC_MAX_SEND_SIZE is stored in the resource 
control block associated with the conversa- 
tion (see "PS.CONV Data Base Structure" on 
page 5.1-1 and "PS.MC Data Base Structure" 
on page 5.2-4 for further details). 


If the length of the data returned from the 
mapper does not exceed MC_MAX_SEND_SIZE, 
PS.MC creates a GDS variable containing a 
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GDS variable containing multiple logical records 


* This data is supplied by the transaction program in an MC_SEND_DATA verb. 


Note: 
GDS ID. 


Figure 


The DATA field of the first, or only, logical 


record in a GDS variable begins with a 2-byte 


Subsequent logical records in the same GDS variable do not carry a GDS ID value. 


5.2-4. 


single logical record. MC_MAX SEND SIZE is 
used only to determine how many logical 
records to create from the datas it is not 
used to determine whether enough data exists 
to be sent to the partner LU. (See Fig- 
ure 5.2-4. ) 

If PS.MC determines that multiple logical 
records are required, the LL fields of all 
but the last logical record have’ the 
high-order bit turned on to indicate that 
the data is continued in the next logical 
record. PS.MC continues to create logical 
records containing data returned from the 
mapper until the end of the data is reached. 
The high-order bit of the LL field of the 
last logical record in the outgoing GDS vari- 
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Transformation of Data from MC_SEND_DATA to a GDS Variable 


able is turned off by the mapper. Fig- 
ure 5.2-4 illustrates the transfer of 


outgoing data from its beginning in the DATA 
parameter of MC_SEND_DATA to its final posi- 
tion in a logical record in a GDS variable. 


When the TP is receiving data, this process 
is reversed. PS.MC continues to receive data 
from PS.CONV until it receives a logical 
record in which the high-order bit of the LL 
field is off. At this point, PS.MC has a 
complete data GDS variable. Next, PS.MC 
strips the GDS ID and LLs from the received 
data, and maps the data according to the cur- 
rently effective map name. The mapped data 
goes into application transaction program 
variables. 
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In either case, exactly one data GDS variable 
is created as a result of each issuance of 
MC_SEND_DATA, and exactly one GDS variable is 
received as aeeresult of each issuance of 
MC_RECEIVE_AND_WAIT. 


FM HEADER DATA 


In LU 6.2, FM header data is normally proc- 
essed by PS rather than by the transaction 
program. All FMHs except FMH-5 (to initiate 
a conversation) and FMH-7 (to report a PS or 
transaction program error) are trapped as 
errors. In LU 6.1, however, an FMH-5 could 
be used for transaction program ‘functions 
(for example, transaction program parameters 
were sometimes encoded in an FMH-5), and 
could flow at any time during a conversation. 
Therefore, in order to allow transaction pro- 
grams that were written for LU 6.1 to run on 
LU 6.2, PS.MC provides a way for transaction 


OF MAPPED CONVERSATION VERB PROCESSING 


As discussed in "PS.MC Functions" on page 
5.2-1, one function of PS.MC is to translate 
mapped conversation verbs and their parame- 
ters into basic conversation verbs and param- 
eters (the other functions relate 
specifically to the mapping of data). The 


functions of PS.MC that relate to verb trans- | 


lation are illustrated and described below. 
(The data-mapping-related functions are 
described in detail in "Data noeP ane and the 
Mapper" on page 5.2-8. ) 


ESTABLISHING A MAPPED CONVERSATION 


A mapped conversation is established when the 
transaction program issues MC_ALLOCATE. 
PS.MC, upon receipt of MC_ALLOCATE from the 
transaction program, performs some initial 
processing. If the processing succeeds, then 
PS.MC issues the basic conversation verb 
ALLOCATE, with TYPE(MAPPED_CONVERSATION), to 
PS.CONV. PS.CONV copies the supplied TYPE 
value into the Resource Type field in the 
FMH-5 that it creates as a result of the 
ALLOCATE. Then, after completing its normal 
ALLOCATE processing, returns’ control to 
PS.MC. 


When the FMH-5 arrives at the target LU, it 
causes the conversation partner transaction 
program to be attached (or invoked). When 
the partner program is attached, it is only 
for the mapped conversation with the trans- 
action program that has just invoked it. It 
may» however, request additional mapped con- 
versations by issuing MC_ALLOCATE verbs of 
its own. 


Once PS.MC returns control to the transaction 
program after processing of the MC_ALLOCATE 
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programs to prevent PS from intercepting the 
FM header data that they are trying to 
exchange. 


If the TP wants to send application data con- 
taining FM headers to its partner, the TP 
issues MC_SEND_DATA with FMH_DATA(YES). This 
causes PS.MC to create a User Control Data 
GDS variable to contain the data. When FM 
header data is contained in a User Control 
Data GDS variable, the sending PS and the 
receiving PS do not process it; they allow it 
to flow directly to the receiving TP. PS.MC 
notifies the receiving TP of the presence of 
FM headers in the received data on the 


MC_RECEIVE AND WAIT verb (see SNA Transaction 


Programmer's Reference Manual for LU Type 
6.2) that the receiving TP issues to receive 


the data. 


Currently, the sole use of User Control Data 
GDS variables on mapped conversations is this 
processing of FM header data. 


1s complete, the transaction program may 
issue mapped conversation verbs on the con- 
versation whose ID was’ returned in_ the 
RESOURCE_ID parameter of the MC_ALLOCATE. © 


PS.VERB_ROUTER prohibits the transaction pro- 
gram from issuing basic conversation verbs 
specifying the resource ID of this mapped 
conversation. When the transaction program 
issues a mapped conversation verb, however, 
PS.VERB_ROUTER allows PS.MC, as part of its 
processing of that verb, to issue a basic 
conversation verb on the same mapped conver- 
sation. See Chapter 5.0 for a further dis- 
cussion of this topic. 


TERMINATING A MAPPED CONVERSATION 


When the transaction program determines that 
its processing related to a mapped conversa- 
tion has completed, or that the mapped con- 
versation should be ended for other reasons, 
it causes the conversation to be terminated 
by issuing MC_DEALLOCATE. PS.MC processes 
this by issuing DEALLOCATE to PS.CONV. How- 
ever, if the MC_DEALLOCATE specified a deal- 
location type of ABEND (see SNA Transaction 
Programmer's Reference Manual for LU Type 

6.2), PS.MC first translates the ABEND va te 

to ABEND _PROG before setting the type of 


deallocation. This reflects the fact that it 
is the transaction program, rather’ than 
PS.MC, that caused the DEALLOCATE to be 


issued. For all other types of deallocation;, 
PS.MC sets the TYPE field of the DEALLOCATE 
to the value specified in that field of the 
MC_DEALLOCATE. 
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DATA MAPPING AND THE MAPPER 


5.2-8 


‘partner by issuing MC_SEND_DATA. 


The transaction program sends data to its 
The partner 
transaction program receives this data by 
issuing MC_RECEIVE_AND_WAIT. Whenever PS.MC 
processes either of these verbs, it passes 
the data through a component called the 
mapper (page 5.2-46). All mapped conversa- 
tion data is thus mapped twice: once when 
sent, and once when received. PS.MC's proc- 
essing of MC_SEND DATA is' called _ send 
mapp 1ng35 its processing _ of 
MC RECEIVE AND WAIT is called receive 
mapping. The particular mappings that the 
mappers perform are determined by the map 
name supplied by the sending transaction pro- 
gram. 


BLOCK MAPPING 


PS.MC performs block mapping, where a block 
is the amount of data contained in one data 
GDS variable (see "Construction of GDS Vari- 
ables" on page 5.2-5 for definitions and 
descriptions of GDS variables). Typically» a 
data GDS variable (or block) resides in a 
transaction program buffer variable dedicated 
to network communication. The ultimate 
source or destination of the data, however, 
is usually one or more other transaction pro- 
gram variables that are significant to the 
transaction program application. A map pro- 
vides an algorithm for transferring data 
between transaction program application vari- 
ables and the transaction program buffer var- 
1able, and for performing any changes in the 
format or representation of the data that 
this transfer may require. Thus, in receive 
mapping, the received data is mapped out of a 
block and into application variables, while 
in send mapping, the data is mapped out of 
application variables and into a block before 
being sent to the conversation partner. 


MAPPING EXAMPLE 


Figure 5.2-5 on page 5.2-9 shows a high-level 
overview of the transformations that map name 
and data undergo during mapping by the send- 
ing and receiving transaction programs. Map- 
ping is symmetric, in that receive mapping is 
basically the inverse of send mapping. 


The transaction program sending data on a 
mapped conversation supplies a map name with 
each issuance of MC_SEND_DATA. The map name 
supplied by the sending transaction program 
determines the Kind of mapping that occurs. 
In the figure, transaction program A issues 
MC_SEND_DATA, supplying MAP_NAME(map-name-1 ) 
and DATA(data-1). PS.MC, as part of its 
processing of this verb, then invokes the 
mapper. PS.MC passes ‘to the mapper 
map-name-1 and data-1. 

The output from the mapper is map-name-2 and 
data-2. Data-2 may be a different size from 
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data-l1 and may be in an entirely different 
format. After reformatting data-2 into a GDS 
variable (by breaking it into logical records 
according to MC_MAX_SEND_SIZE, and prefixing 
a GDS ID), PS.MC sends map-name-2 and data-2 
to the partner LU. 


When the data arrives, the PS.MC component at 
the partner LU processes the 
MC RECEIVE AND WAIT by repeatedly issuing 
RECEIVE AND WAIT with a fill value of LL. 
PS.MC accumulates the data, one _ logical 
record at a time, until it receives a logical 
record whose LL field indicates that it is 
the final logical record of the incoming data 
GDS variable. At this point, PS.MC has one 
complete data GDS variable. It then strips 
the GDS ID and LLs», and invokes the mapper, 
passing it map-name-2 and data-2. Here, at 
the receiving LU, the map name and data once 
again go through a_ée transformation. The 
receiving mapper transforms map-name-2 and 
data-2 into map-name-3 and data-3,» and 
returns these to the receiving transaction 
program in the MAP_NAME and DATA parameters 
of MC_RECEIVE_AND_WAIT (only the amount of 
data requested by the transaction program is 
passed to it; any remaining data that is not 
requested and returned is discarded). Data-3 
may again differ in size and format from 
data-2, or from data-l. Map-name-3, similar- 
ly» may be different from map-name-2 and 
map-name-1. In the simplest case, the three 
map names are identical. 


“Send Mapping" on page 5.2-10 "Receive Map- 
Ping" on page 5.2-11 show more details of the 
processing of MC_SEND_DATA and 
MC_RECEIVE_AND_WAIT. 


MAP NAMES 


With every issuance of MC_SEND_DATA, the 
transaction program supplies a map name to 
PS.MC and the mapper. Similarly» on every 
issuance of MC_RECEIVE_AND_WAIT, the mapper 
returns a map name to the transaction pro- 
gram. The sending transaction program may 
supply the same map name repeatedly, and the 
same map name may be received repeatedly by 
the receiving transaction program, but the 
sending PS.MC. does not send consecutive 
duplicate map names. Instead, the locally 
Known map name supplied by the transaction 
program is translated into a globally Known 
map name and stored in the MAPPER_SAVE_AREA 
as the currently effective map name. This 
map name is similarly stored by the receiving 
PS.MC. The sending PS.MC sends (and the 
receiving PS.MC receives) a new map name only 
when the currently effective map name 
changes. The currently effective map name 
changes when the map name supplied by the 
sending transaction program is’ translated 
into a globally Known map name that differs 
from the currently effective one stored in 
the MAPPER_SAVE_AREA. When the mapper dis- 
covers this difference, it updates the cur- 


C 


orm 


————— 
rad 


C- 


(Sending LU) 
PS.MC PS .MC 
(MAPPER ) (MAPPER ) 


(Receiving LU) 


map-name-1, data-1 é ; ; 
0 


map-name-2, data-2 : ; 
onr_—_—_——-———“——?.nnknmkre—=—=—=—-— — a—av—x—X—x—rn—eaeeeeo 0 e 
map-name-3, data-3 ‘ 


———_—_—_—_—_—_—“—a—ana:*X_—SX—XXSX OO 


dy! Map-name-1 and data-1 are supplied by the sending transaction program on MC_SEND_DATA. Map-name-2 
“and data-2 flow from sending PS.MC to receiving PS.MC as GDS variables. Map-name-3 and data-3 are 
' passed to the receiving transaction program via MC_RECEIVE_AND_WAIT . 


See "Mapping Example" for an explanation of the flows shown in this figure. 


Figure 5.2-5. An Example of Mapping 


rently effective map name in its 
MAPPER_SAVE_AREA, and informs PS.MC of this 
change by returning an indicator and the new 
map name. 


The mapper can translate map names in many 
different ways. It may, for example, trans- 
late the supplied map name to null, thereby 
preventing the data from being transformed. 
The mapper may also translate two different 
locally Known map names to the same globally 
Known map name. For instance, if the trans- 
action program issues MC_SEND_DATA with map 
name A followed by another MC_SEND_DATA with 
map name B, the mapper may map both map names 


to map name C. Moreover, the mapper may 
translate the same locally Known map name 
differently on different occasions. If the 


transaction program issues MC_SEND_DATA with 
map name A and the mapper translates it to 
map name B, then when the transaction program 
again issues MC_SEND_DATA with map name A, 
the mapper may, because of information Known 
only to itself, translate this map name to 
map name C. Nevertheless, the translation of 
map names by the mapper is subject to some 
constraints. For example, the mapper never 
translates a null map name to a nonnull map 
name. 


Map Name GDS Variables 


To complete its processing of a change in the 
effective map name, the sending PS.MC must 
notify the receiving PS.MC of the change. It 
does this by sending to the receiving PS.MC a 
Map Name GDS variable containing the new 
effective map name. In this situation, a 
single MC_SEND_DATA causes two GDS variables 


to be created: a Map Name GDS variable and a 
data GDS variable. 


Similarly, the receiving mapper saves, in its 
MAPPER_SAVE_AREA, the map name received ina 
Map Name GDS variable. When subsequent data 
GDS variables are received with no interven- 
ing Map Name GDS variables, the mapper uses 
the saved map name in mapping the new data. 
Once a Map Name GDS variable is received, 
that map name remains in effect. until another 
map name is received or the mapped conversa- 
tion ends. : 


When the effective map name is null (with a 
length of zero), mapping is said to be "off"; 
that is, any data passed to the mapper is 
returned unchanged. At the beginning of all 
mapped conversations, the effective map names 
are initialized to null. This happens prior 
to any flow of Map Name GDS variables. A Map 
Name GDS variable containing a null map name 
is sent to the partner only to change the 
effective map name back to null after it has 
not previously been null. If the transaction 
Program always supplies a null map name, no 
Map Name GDS variable is ever sent to the 
partner LU. 


MAPPER INVOCATION 


PS.MC invokes the mapper whenever any of the 
following occurs: 


e The transaction program sends or receives 
data (that 1s, issues MC_SEND_DATA or 
MC_RECEIVE_AND_WAIT). The data may be 
application data or FM header data; both 
of these types of data may be mapped. 
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® PS.MC receives, from PS.CONV, information 
indicating that the partner transaction 
program has received and processed all 
the recently sent map _ names. This 
includes information such as a positive 
reply to CONFIRM or to SYNCPT, or any 
information that the partner transaction 
program issued from SEND state (see 
explanation below). 


The mapper is also invoked during the error 
processing triggered by the events listed 
below. This processing is more thoroughly 
described in "Mapper Errors" on page 5.2-12. 
e =§6 The transaction issues 
MC_SEND_ERROR. 


program 


e PS.MC issues SEND_ERROR with a type value 
of SVC (see SNA Transaction Programmer's 
Reference Manual for LU Type 6.2). 

e The transaction program or the sync point 
manager ("Chapter 5.3. Presentation Serv- 
ices--Sync Point Services Verbs") issues 
BACKOUT. 


e A return code of SVC_ERROR_* is received 
from PS.CONV. 


e A return code of PROG_ERROR_* is received 
from PS.CONV. 


A positive reply to CONFIRM or to SYNCPT 
informs the mapper that any map names it has 
caused to be sent to the partner have been 
received and processed by it. For example, 


‘if the mapper causes a Map Name GDS variable 


to be sent to the partner LU, and is informed 
that a positive reply to CONFIRM has been 
received, and is next invoked because the 
partner LU detected an error while in RECEIVE 
state, the mapper Knows, because of the 
intervening confirmation, that the error 
processing at the partner did not cause the 
map name to be purged. The mapper does not 
cause a duplicate map name to be sent in this 
case. 


In addition, receipt of data from the partner 
also indicates that all the recently sent map 
names have been processed, because the part- 
ner cannot have sent data unless it has 
entered SEND state, and it cannot have 
entered SEND state (from RECEIVE state, which 
is the state it was in when it was receiving 
and processing the data sent by the trans- 
action program) unless it has’ finished 
receiving and mapping all the data that the 
transaction program was sending. Moreover, 
not only receipt of data, but receipt of any 
information whatsoever that the partner 
issued from SEND state (such as a SEND indi- 
cator, CONFIRM, or even an error notifica- 
tion) indicates to the mapper that the 
partner has received and processed the most 
recently sent map names. 


MAPPER PARAMETERS 


Each time PS.MC invokes the mapper, it sup- 
plies required information to the mapper. 
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PS.MC. 


This information includes, in addition to the 
map name and the data to be mapped, such 
information as whether send or receive map- 
ping is to be performed. Also, based upon 
the reason for the mapper invocation, infor- 
mation may be returned by the mapper to 
The mapper also uses other data 
structures in the RCB_ to store currently 
effective map names and incoming data. The 
information used and returned by the mapper 
is listed below. For a further description 
of mapper input and output, see the formal 
description of the UPM_MAPPER on page 5.2-46. 


Supplied Information 


® Reason for the mapper invocation 
- Data mapping 
= Errors 
—- Positive confirmation 
¢ Data polarity 
—- Send 
—- Receive 
e FMH data indicator 
e¢ Input map name 
e Input data 


e Error code 


Returned Information 


e Output map name 
e¢ Output data (mapped data) 


¢ Mapper return code 


SEND MAPPING 


When the transaction program is sending data 
(i.e.> when PS .MC is processing 
MC_SEND_DATA), the mapper is responsible for: 


e¢ Mapping the data supplied by the trans- 
action program (in the verb's DATA param- 


eter) in accordance with the MAP_NAME 
parameter supplied by the transaction 
program 


® Mapping the locally Known map name sup- 
plied by the transaction program to a 
globally Known map name corresponding to 
the format of the mapped data 


¢ Determining whether to send a Map Name 
GDS variable to the partner LU, and pre- 
venting duplicate Map Name GDS variables 
from flowing consecutively to the partner 
LU 
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¢ Determining whether to resend a Map Name 
GDS variable to the partner LU, in the 
event of an error 


PS.MC's processing of MC_SEND_DATA is 
described below. For example, the trans- 
action program issues MC_SEND_DATA with 
MAP_NAME(A) and DATA(data-1). PS.MC invokes 
the mapper, informing it that send mapping is 
to be performed. PS.MC also passes to the 
mapper the supplied map name and data. 


The mapper translates map name A to map name 
B and maps data-l to data-2, to be sent to 
the partner LU. The translated map name, 
Since it differs from the currently effective 
map name (which is stored in the 
MAPPER_SAVE_AREA and is initially null) is 
returned to PS.MC. The translated data is 
also returned. 


When control is returned to PS.MC from the 
mapper call, PS.MC first determines whether 
the mapper succeeded in mapping the supplied 
data (1t could have failed if the trans- 
action program had provided a map _ name 
unknown to the mapper). Since the mapping 
was successful, PS.MC next determines whether 
a new map name has been returned. In this 
case, the mapper has returned the output map 
name, because the translated map name B dif- 
fers from the currently effective map name. 
Therefore, PS.MC updates the currently effec- 
tive map name to B and creates a Map Name GDS 
variable (to be sent to the partner) contain- 
ing map name B. PS.MC next formats the data 
returned by the mapper as a an Application 
Data or User Control Data GDS variable, by 
segmenting it into logical records and pre- 
fixing the GDS ID. PS.MC uses-~ the 
MC_MAX_SEND_SIZE field in the RCB to deter- 
mine the size of the logical records. 


Finally, PS.MC issues SEND_DATA, with a DATA 
parameter containing the Map Name and data 
GDS variables. When the SEND_DATA completes 
successfully, PS.MC returns control to the 
transaction program, indicating that the 
MC_SEND DATA was also successful. 


When the transaction program again issues 
MC_SEND_DATA, again specifying a map name of 
A, PS.MC again invokes the mapper. As in the 
previous invocation, the mapper translates 
map name A to map name B. Since it has 
already caused PS.MC to send map name B to 
the partner LU, it does not return an output 
map name to PS.IMC. 


Since no map name was’ returned from the 
mapper, PS.MC does not create a Map Name GDS 
variable. It processes the output data as 
above, creating an Application Data or User 
Control Data GDS variable containing the 
data. Finally, it issues SEND_DATA with a 
DATA parameter containing only the data GDS 
variable. An OK return code is returned on 
the SEND_DATA, and PS.MC returns a return 
code of OK on the MC_SEND_DATA. 


RECEIVE MAPPING 


When the transaction program is receiving 
data (1.e., when PS.MC is_ processing 
MC_RECEIVE_AND_WAIT), the mapper is responsi- 
ble for 


e Mapping the data received from the part- 
ner LU in accordance with the currently 
effective map name, 


e¢ Mapping the currently effective map name 
to a locally Known map name corresponding 
to the format of the mapped data, and 
returning this map name and the mapped 
data to the transaction program, and 


e Optionally, checking incoming Map Name 
GDS variables from the partner LU for 
duplication and symbol-string consisten- 


cy. 


An example of PS.MC's processing’. of 
MC_RECEIVE_AND_WAIT is described below. 


First, PS.MC issues the basic conversation 
verb RECEIVE_AND_WAIT to PS.CONV, specifying 
a fill value of LL (see SNA Transaction Pro- 


record. After the RECEIVE_AND_WAIT completes 
successfully, PS.MC finds that the data 
received consists of a Map Name GDS variable. 
Knowing that a data GDS variable is to follow 
the map name » PS .MC again issues 
RECEIVE_AND_WAIT to PS.CONV, again retriev- 
ing one logical record. The data received in 
the second RECEIVE_AND_WAIT is application or 
FM header data, but the high-order bit of the 
LL field in the logical record indicates that 
more data follows that is to be associated 
with the data just received; that is, the 
data GDS variable consists of multiple log- 
ical records (see "Construction of GDS Vari- 
ables" on page 5.2-5). PS.MC continues to 
request data from PS.CONV- until the 
high-order bit of the LL field of the 
received logical record is off, indicating 
that -the entire data GDS variable has been 
received. In the example, this occurs on the 
third RECEIVE _AND_WAIT. 


PS.MC has now received a map name and data to 
be mapped. It ainvokes the mapper = and 
receives from the mapper the map name and 
mapped data to be passed to the transaction 
program. PS.MC passes to the transaction 
program the amount of data that the trans- 
action program has requested, and discards 
any remaining data. 


MC TEST PROC 


An implementation of the mapped conversation 
verbs includes an entry point, MC_TEST_PROC, 
which can be used to determine whether a com- 
plete data GDS variable has been received 
from the remote TP without causing the call- 
ing program to wait if data is not available 
immediately. This entry point is called by 
the implementation of the WAIT verb, which 
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enables a TP to wait for arrival of data on 
any of a list of basic and mapped conversa- 
tions. 


An MC_POST_ON_RECEIPT verb must be issued 
before a call to MC_PROC_TEST is effective. 
Thus, MC_POST_ON_RECEIPT must be issued 
before a WAIT verb that includes a mapped 
conversation in its list. Then a sequence of 
calls can be made to MC_TEST_PROC, which 
returns the code OK when a complete data GDS 
variable is available. 


In order to determine whether a complete data 
GDS variable has been received from the 
remote TP, MC_TEST_PROC has to issue a 
RECEIVE_AND_WAIT verb, so that it can examine 
the data. Several RECEIVE _AND_WAIT verbs may 
be required before a complete data GDS vari- 
able is received. As the pieces of the data 
GDS variable are received, they are placed in 
an RCB field, MC_RECEIVE_BUFFER, where they 
are held until the local TP issues an 
MC_RECEIVE_AND_WAIT verb. 


To make sure that the RECEIVE _AND_WAIT verbs 
that 1t issues do not cause waits for data to 
be received from the remote TP, MC_TEST_PROC 
calls a similar entry point of PS.CONV; 
TEST_PROC, to determine whether a logical 
record has already been received. Only when 
such a record is available does it issue a 
RECEIVE_AND_WAIT verb. 


An example of the use of MC_TEST_PROC is 
illustrated in Figure 5.2-6 on page 5.2-13 
and described below. This figure begins with 
the TP issuing an MC_POST_ON_RECEIPT verb for 
a specified mapped conversation. It then 
issues a WAIT verb, which causes’ the 
PS.VERB_ROUTER to call MC_TEST_PROC for the 
specified conversation, as well as others. 
MC_TEST_PROC first checks the 
MC_RECEIVE_BUFFER in the RCB associated with 
the conversation to see if it holds a com- 
plete data GDS variable. In this example, 
PS.MC does not have a data GDS variable 
ready. Therefore, MC_TEST_PROC calls 
TEST_PROC to determine whether PS.CONV has 
any data ready to be received. PS.CONV 
returns to PS.MC with a code indicating that 
data is avallable, WHAT_RECEIVED = 
DATA_COMPLETE. PS.MC issues RECEIVE_AND WAIT 
to retrieve the waiting data. After inspect- 
ing the data, PS.MC discovers that it is not 


MAPPED CONVERSATION ERRORS 
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MAPPER ERRORS 


In send mapping, the supplied map name is not 
checked for symbol-string consistency; its 
symbol-string restrictions, if any», = are 
implementation-defined. The mapper’ trans- 
lates the supplied map name to a globally 
Known map name that conforms to the 
symbol-string definitions in the SNA Trans- 
action Programmer's Reference Manual for LU 


Type 6.2. PS.MC, therefore, also performs no 
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sufficient to complete the current data GDS 
variable. PS.MC stores the received data in 
MC_RECEIVE BUFFER, issues POST_ON_RECEIPT to 
request that PS.CONV reinitiate posting» and 
returns the code UNSUCCESSFUL to 
PS.VERB_ROUTER. PS.VERB_ROUTER resumes test- 
ing this resource and all others specified in 
the WAIT verb for receipt of a complete data 
GDS variable. 


In this example, had the call to TEST_PROC 
returned any code other than OK--DATA, PS.MC 
would not issue RECEIVE_AND_WAIT but would 
return to PS.VERB_ROUTER the same code that 
it received from TEST_PROC. On the other 
hand» had the data returned by 
RECELVE_AND_WAIT completed a data GDS vari- 
able, MC_TEST_PROC would not have issued 
POST_ON_RECEIPT but would have returned the 
code OK--DATA to PS.VERB_ROUTER. 


When MC_TEST_PROC is called, 
MC_RECEIVE_ BUFFER is in one of the following 
states: 


It is empty. 
It contains the initial logical records 
of a data GDS variable (perhaps preceded 
by an associated map name GDS variable), 
but does not yet contain the remaining 
logical records of the data GDS variable, 
which must be received before the data 
can be passed to the transaction program. 
° It contains a complete data GDS variable 
that is ready to be mapped and passed to 
the transaction program. 


Once a complete data GDS variable has been 
received, PS.MC requests no more information 
from PS.CONV until it passes to the trans- 
action program the data already in 
MC_RECEIVE_ BUFFER. 


MC_RECEIVE_BUFFER may contain many different 
types of information. It may contain tran- 
sient information, such as a return code or a 
SEND indicator, which i1s_ returned to the 
transaction program as soon as processing of 
the current verb is completed. It may con- 
tain part or all of a data GDS variable. 
These logical records remain in the list 
until the incoming data GDS variable is com- 
plete and is retrieved by RECEIVE_AND_WAIT. 


checking of the globally Known map name 


returned by the mapper; the mapper is respon- 
sible for supplying map names that conform to 
SNA-defined formats. In receive mapping, 


however, the mapper does check the map name 
received in a Map Name GDS variable for 
symbol-string consistency. The mapper 


informs PS.MC via a- return’ code. of 
MAP_NOT_FOUND when the map name violates 
SNA-defined symbol-string types» or when the 
map name conforms to defined symbol-string 
types but is unknown to the mapper (see SNA 
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PS.VERB_ROUTER 


MC_POST_ON_RECEIPT 


PS .MC PS .CONV 


(MC_RECEIVE BUFFER does not hold 
a complete data GDS variable) 


; Call TEST_PROC 
rn nn nnn nn nk _ _=_ en SO 


return code = OK--DATA 


(PS.CONV has data) 


. RECEIVE_AND_WAIT (FILL = LL). 
o_o 


~WHAT_RECEIVED = DATA_COMPLETE. 


(more data to be received) 


. POST_ON_RECEIPT (FILL = LL) 
oo 0 


return code = UNSUCCESSFUL 


Continue testing for posting by 
any resource specified in the verb 


See "MC_TEST_PROC" on page 5.2-11 for an explanation of the flows shown in this figure. 


Note: 


Figure 5.2-6. 


Only those parameters pertinent to the example are shown. 


MC_TEST_PROC 


Formats for definitions’ of the valid 


symbol-string types). 


The mapper also performs an optional receive 
check to determine if it has received a map 
name that is the duplicate of the map name 
last received. If it has,» then the mapper 
informs PS.MC, which ends the mapped conver- 
sation. See "Protocol Violations" on page 


6.2-14 for details. 


If notification of an error is _ received, 
PS.MC passes the error notification to the 
transaction program as a return code. In 
addition, PS.MC invokes the mapper to inform 
it of the error. The mapper then determines 
whether a map name needs to be re-sent, since 
the MC_SEND_ERROR issued by the partner 
transaction program or PS.MC might have 
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caused the map name to be purged on receipt. 
If notification of an error is received and 
the mapper has previously caused PS.MC to 
send a map name to the partner LU, the mapper 
checks to see if any information has _ been 
received that would indicate that the partner 
LU has received and processed the map name. 
Examples of the type of information that 
would indicate this are an affirmative reply 
to CONFIRM or to SYNCPT, received data, or a 
SEND indicator. If none of the above has 
been received, the mapper causes a map name 
to be re-sent to the partner LU. The map 
name that is sent is based upon the map name 
supplied by the transaction program on the 
next MC_SEND_DATA. 


The mapper needs to be informed of any errors 
that occur on a mapped conversation, and of 
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any issuances of BACKOUT that occur on a 
mapped conversation whose synchronization 
level is SYNCPT, because these events may 
require the mapper to re-send the currently 
effective map name. In the case of an error 
detected by the partner LU, a map name that 
the mapper has sent to the partner may have 
been purged by the partner as a result of its 
error processing. Therefore, the mapper has 
to determine whether it needs to re-send the 
map name that may have been purged. In the 
case of BACKOUT, the entire mapped conversa- 
tion is required to revert to the status it 
had at the last issuance of SYNCPT. If the 
currently effective map name has_ changed 
since then, the mapper needs to resend the 


map name that was in effect at the last issu- 


ance of SYNCPT. 


ERROR DATA GDS VARIABLES 


A GDS variable that is not created as a 
direct result of action taken by the trans- 
action program is the Error Data GDS vari- 
able. When PS.MC detects an error in the 
data being received from the partner LU, it 
issues a SEND_ERROR TYPE(SVC) followed by a 
SEND_DATA. The DATA’ parameter of _ the 
SEND_DATA contains the Error Data GDS vari- 
able, which describes the exact nature of the 
error encountered. The transaction program 
serviced by the PS.MC that received the data 
and detected the error is not informed of the 
error. The transaction program that issued 
the data in which an error was found is told 
of the error via a return code derived from 
the information contained in the Error Data 
GDS variable (see “Processing of a Service 
Error Detected by Partner LU" on page 
5.2-17). An example’ of the type of error 
that PS.MC might encounter in received data 
1s receipt of a User Control Data GDS vari- 
able when FM header data is not supported by 
the transaction program or the LU. 


PROTOCOL VIOLATIONS 


PS.MC performs optional receive checks to 
determine if the partner LU has committed a 
protocol violation. An example of a protocol 
violation PS.MC can detect is the receipt of 
a Map Name GDS variable followed by something 
other than a data GDS variable (map names 
have to be followed by data). 


When PS.MC detects a protocol violation such 
as the one above, it issues DEALLOCATE with 
TYPE(ABEND_SVC) and returns a return code of 
RESOURCE_FAILURE_NO_RETRY to the transaction 
program. Correspondingly > when PS.MC 
receives a return code of DEALLO- 
CATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER from 
PS.CONV, it translates the return code to 
RESOURCE_FAILURE_NO_RETRY;, and passes it to 
the transaction program. 


If, however, the protocol violation occurred 
because the mapped conversation ended’ prema- 
turely at the partner LU (1.e., the partner 
LU has issued a deallocation notification 
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that indicates a protocol error), then PS.MC -~ 


simply logs the error and = passes_ the 


RESOURCE_FAILURE_NO_RETRY return code to the\__- 


transaction program. Since the mapped con- 
versation has already been deallocated at the 
partner LU, PS.MC cannot issue the DEALLOCATE 
(TYPE=ABEND_SVC) that it normally issues. when 
it detects a protocol violation. 


SERVICE ERRORS 


The TP, upon detecting an error on a mapped 
conversation, issues MC_SEND_ERROR- with 
TYPE(PROG). This indicates that the type of 
error detected was a program error (1.e.,) was 
an error discovered by a TP). Another cate- 
gory of errors may be detected by the LU 
rather than the TP. These errors are called 
service errors because they are detected by a 


presentation services component within the” ~* 


LU. 


As a service component, PS.MC checks for cer- 
tain types of service errors. If a partner 
TP requests a function, such as handling of 
function management header (FMH) data, that 
is not supported by the local LU or trans- 
action program, PS.MC performs service error 
processing and advises the partner LU of the 
lack of support for that function. 


Another service error that PS.MC may detect 


is receipt of a map name from the partner Lu-~ 


that is not Known by the mapper. Similarly 


the mapper may find that the data and the map.’ 


name it has received from the partner LU are 
incompatible, i.e., that the data cannot be 
mapped using the received map name. 


PS.MC also handles receipt of a service error 
notification from a partner LU when it is the 
partner that discovered the service error. 


The following sections describe the process- 
ing that PS.MC performs when it detects a 
service error, and the’ processing 


detected an error. 
SERVICE ERRORS DETECTED IN RECEIVED DATA 


As mentioned earlier, one type of error that 
PS.MC may detect is receipt of an invalid map 
name. Figure 5.2-7 on page 5.2-15 illus- 
trates this service error. In the figure, 
PS.MC has issued a RECEIVE_AND WAIT to 
PS.CONV as a result of the 
MC_RECEIVE_AND_WAIT issued by the TP. The 
data returned in the RECEIVE_AND_WAIT is a 
Map Name GDS variable. PS.MC stores the map 
name and issues another RECEIVE_AND_WAIT in 
order to receive the data that follows the 
map name. In this example, PS.MC receives a 
complete data GDS variable in the 
RECEIVE_AND_WAIT (and therefore does not,~. 
retrieve any more data from PS.CONV). ( 
PS.MC invokes the mapper, passing it the 
received map name and data. Instead of map- 
ping the data, however, the mapper returns to 


that ~~ 
results when PS.MC learns that the paper 


TP PS .MC MAPPER PS .CONV 


MC_RECEIVE_AND_WAIT . RECEIVE AND “WAIT (FILL = LL) 
i a 


WHAT_RECEIVED = DATA_COMPLETE 


(data 1s a map name GDS variable) : 
; RECEIVE AND WAIT (FILL = LL) ; 
hoy 
WHAT_RECELVED = DATA_COMPLETE 
(data is a complete data GDS variable) 
INPUT_DATA=data-1 
INPUT_MAP_NAME=map-name-1 
SSS SO 
RETURN_CODE=MAP_NOT_FOUND 


: SEND_ERROR (TYPE = SVC) ‘ 
$$$ ee 


; SEND_DATA (DATA = Error Data GDS variable) , 
nt. Y «| 


; PREPARE_TO_RECEIVE (TYPE = FLUSH) - 
a EY 


; RECEIVE _AND_WAIT , 
i et >) 


. ‘ WHAT_RECEIVED = DATA_COMPLETE ‘ 


See "Service Errors Detected in Received Data" for an explanation of the flows shown in this figure. 
Figure 5.2-9 on page 5.2-18 is the complement of this figure, showing the processing that occurs 


when an LU is informed of an error committed at that LU. Note: Only those parameters pertinent to 
the example are shown. 


Figure 5.2-7. Detecting a Service Error as a Result of MC_RECEIVE_AND_WAIT Processing 


PS.MC a return code indicating that the map PS.MC now has to inform the partner that a 
name received is invalid. The mapper has | service error occurred and to return SEND 
detected a service error and informed PS.MC control of the mapped conversation to the 
of the error. partner TP. PS.MC first issues SEND_ERROR 


with TYPE(SVC). This tells the partner LU 
only that an error occurred; it does not 


Chapter 5.2. Presentation Services--Mapped Conversation Verbs 5.2-15 


PS.VERB_ROUTER ~ PS.MC PS .CONV C 


Call MC_TEST_PROC 


. TEST . 


oO OO ee ee Leer DOD 


RETURN_CODE = OK : 


RECEIVE_AND_WAIT (FILL = LL) 


© ee A 


WHAT_RECEIVED = DATA_COMPLETE 


PS.MC examines the data 
and detects an error) 


SEND_ERROR (TYPE = SVC) 


=S 


fom, 
oC OOOO ( 
MS 
RETURN_CODE = OK 
o- ---- ee He ee ee eH eH KH HH eH eH ee ee oO 
SEND_DATA (DATA = Error Data GDS variable) 
oo 0 
‘. RETURN_CODE = OK 
Sa Se a es Se ge a: es a ee ee ee ee a es ee Oo 
PREPARE_TO_RECEIVE (TYPE = FLUSH) 
© 2) 
° e . 
RETURN_CODE = OK ( | 
Se 


POST_ON_RECEIPT (FILL = LL) 


o_O 


RETURN_CODE = UNSUCCESSFUL 


See "Service Errors Detected in Received Data" for an explanation of the flows shown in this figure. 


Note: 


Figure 5.2-8. 
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Only those parameters pertinent to the example are shown. 


indicate to the partner the exact nature of 
the error. In order to convey this important 
information to the partner, PS.MC creates an 
Error Data GDS variable. The GDS variable 
carries an indication that the received map 
name was not found in the mapper's library of 
map names; the invalid map name is also 
returned to the partner LU in the Error Data 
GDS variable so that the partner LU will Know 
exactly which map name was unknown. PS.MC 
then issues a SEND _DATA carrying the Error 
Data GDS variable to PS.CONV. 


PS.MC completes its processing of the 
received service error by issuing  PRE- 
PARE_TO_ RECEIVE with TYPE( FLUSH), which 


returns SEND control of the mapped conversa- 
tion to the partner TP. 
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Detecting a Service Error as a Result of a Call to MC_TEST_PROC 


PS.MC does not inform its local TP of the 
service error committed by the partner LU. 
It instead returns SEND control of the mapped 
conversation to the partner TP, which is 
informed of the error, and waits for the 
partner TP to recover from the error. The 
transaction program that committed the error 
is responsible for determining what error 
recovery is to take place. When the service 
error is detected as aeresult of an 
MC_RECEIVE_AND_WAIT, PS.MC immediately issues 


another RECEIVE_AND_WAIT to wait for informa- 


tion from the partner. 


Figure 5.2-8 illustrates a slightly different 
situation in which a= service error. is 
detected. This time, the error is detected 
in data that was received as a result of a 
call to MC_TEST_PROC by the PS.VERB_ROUTER 
while it is processing a WAIT verb. Another 
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difference is that instead of the mapper. 


detecting the error, PS.MC discovers it. One 
cause of this type of error would be incoming 
data requesting a function that the receiving 
PS.MC did not support (for example, the func- 
tion of handling FM header data when User 
Control Data GDS variables are not supported 
by the receiving PS.MC). 


In handling this error during a call to 
MC_TEST_PROC, PS.MC, as in the 
MC_RECEIVE_AND_WAIT example, issues 
SEND_ERROR, followed by SEND_DATA with an 
Error Data GDS variable, followed by PRE- 
PARE_TO_RECEIVE with TYPE(FLUSH). PS.MC then 
continues, however, in a manner different 
from the MC_RECEIVE_AND_WAIT example: 
MC_TEST_PROC returns to the PS.VERB_ROUTER, 
after passing SEND control of the mapped con- 
versation to the partner (and after causing 
posting to be re-activated). The 
PS.VERB_ROUTER is informed that its MC_TEST 
was unsuccessful, but not of the specific 
error. 


PROCESSING OF A SERVICE ERROR DETECTED BY 
PARTNER LU 


PS.MC also handles service errors that are 
detected by the partner LU. The error could 
have been detected in data sent to the part- 
ner LU by the local TP. Alternatively, the 
partner LU may have detected an error while 
sending data to PS.MC. Figure 5.2-9 on page 
5.2-18 and Figure 5.2-10 on page 5.2-19 
illustrate these two cases of error notifica- 
tion. 


In Figure 5.2-9 on page 5.2-18, the trans- 
action program is in the midst of sending 
data to the partner’ transaction § program. 
However, a return code of SVC_ERROR_PURGING 
is returned on one of the SEND_DATAs that 
PS.MC issues to PS.CONV. The 
SVC_ERROR_PURGING return code indicates that 
the partner LU has detected an error in the 
data it has received. PS.MC, upon receipt of 
the SVC_ERROR_PURGING return code, issues a 
RECEIVE_AND_WAIT to learn the type of service 
error the partner LU encountered. The data 
returned in the RECEIVE_AND_WAIT consists of 
an Error Data GDS variable specifying the 
type of service error. The return code that 
PS.MC returns to the transaction program is 
derived from the information carried in the 
Error Data GDS variable. Before returning to 
the transaction program, PS.MC issues another 
RECEIVE_AND_WAIT to retrieve the SEND indica- 


tor. As discussed in the previous section, 
the transaction program that caused a service 
error to be committed is responsible for 
determining what error recovery is to occur. 
PS.MC returns to the transaction program with 
a return code, in this’ example, of 
MAP_NOT_FOUND. The transaction program still 
has SEND control of the mapped conversation 
(the transaction program is placed in SEND 
state as a result of a remotely detected 
error, even if the transaction program was in 
RECEIVE state when it issued the verb on 
which the error is reported). 


The example shown in Figure 5.2-7 on page 
5.2-15 and described in "Processing of a 
Service Error Detected by Partner LU" is the 
complement of the example just discussed and 
shown in Figure 5.2-9 on page 5.2-18. The 
first figure mentioned shows a_ transaction 
program requesting to receive data on a 
mapped conversation and the LU detecting an 
error in the data received. The second fig- 
ure shows a transaction program sending data 
on a mapped conversation and being notified 
that a problem with the data was encountered 
at the partner LU. 


As was pointed out in “Block Mapping" on page 
5.2-8)> PS.MC never sends a service-error 
notification to its partner from SEND state. 
An LU providing implementation-defined map- 
Ping, however, could issue such an error. 
For example, the LU may have mapped some, but 
not all, of the data issued by the trans- 
action program in an MC_SEND_DATA. The part 
of the data that has been mapped is sent on 
the mapped conversation. While mapping the 
remainder of the data, however, the mapper 
discovers a problem. It informs its PS.MC 
component, which then issues a service-error 
notification indicating that data truncation 
has occurred at the sending LU. An LU with 
implementation-defined mapping may also, at 
some point, need to notify its partner that 
an error was detected but no data truncation 
has occurred. 


While PS.MC does not issue service errors 
from SEND state, it does handle receipt of 
notifications that the partner LU detected a 
service error while it was in SEND state. 
Figure 5.2-10 on page 5.2-19 illustrates the 
processing that PS.MC performs as a result of 
this error. If it has received any incom- 
plete data prior to receiving the 
service-error notification, PS.MC purges the 
data and immediately begins to wait for new 
data to arrive. Again, the transaction pro- 
gram is not informed of the error. 
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Tt | PS.MC_ PS .CONV (C : 


: MC_SEND_DATA : SEND_DATA ; 
i a 
: RETURN_CODE = OK a RETURN_CODE = OK : 
Cree Km Ke nm me em mee em e wm em Oe me eK Kr em ee ee em errr errr reece fe) 
@ 
@ 
e 
MC_SEND_DATA SEND_DATA | 
a a a eg 
: ‘ RETURN_CODE = SVC_ERROR_PURGING ' 
o<- -------------------- ) 
. : RECEIVE_AND_WAIT ; 
0 
; . WHAT_RECEIVED = DATA_COMPLETE : C- 


. (data is an error.data GDS variable) 


. . RECEIVE AND_WAIT . 


: 0 
RETURN_CODE = MAP_NOT_FOUND . WHAT_RECEIVED = SEND 
oc --------------- ----0o- ---------------------- o 


See "Processing of a Service Error Detected by Partner LU" for an explanation of the flows that are ~~~. 
shown in this figure. 

Figure 5.2-7 on page 5.2-15 is the complement of this figure, showing the processing that occurs at 

the LU that detects an error in received data. The SVC_ERROR_PURGING return code can be returned on 
several verbs. SEND_DATA is used here as an example of one of the verbs possible. 


Note: Only those parameters pertinent to the example are shown. 


Figure 5.2-9. Receipt by PS.MC of a SVC_ERROR_PURGING Return Code 
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TP PS.MC . PS.CONV 


: MC_RECEIVE_AND_WAIT ‘ RECEIVE _AND_WAIT (FILL = LL) 


a a ea ee 


.RETURN_CODE = SVC_ERROR_TRUNC/SVC_ERROR_NO_TRUNC 


‘ (PS.MC purges any data that it has received 
‘ prior to the service error notification) 


RECEIVE_AND_WAIT 


aR Te 


See "Processing of a Service Error Detected by Partner LU" for an explanation of the flows that are 
shown in this figure. 


The processing that occurs when a SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC return code is received by 
PS.MC while processing a call to MC_TEST_PROC differs from this figure only in that PS.MC does not 


issue a RECEIVE_AND_WAIT after receiving the return code. PS.MC returns a code of UNSUCCESSFUL to 
the PS.VERB_ROUTER. 


Note: Only those parameters pertinent to the example are shown. 


Figure 5.2-10. Receipt by PS.MC of a SVC_ERROR_TRUNC orSVC_ERROR_NO_TRUNC Return Code 
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PS _MC 


5.2-20 


PS MC 


FUNCTION: 


INPUT: 


OUTPUT: 


This procedure receives mapped conversation verbs issued by the transaction 
program, and routes each verb to the appropriate procedure for processing. 


PS.MC is called by PS.VERB_ROUTER (Chapter 5.0) as a result of the transaction 
program's issuing a mapped conversation verb. 


The current transaction program verb is passed with parameters; 
PS PROCESS_DATA is provided by the resources manager at creation time and may 
be accessed by all the procedures within PS. 

Refer to the procedures that are called from this procedure for the specific 
outputs. 


Referenced procedures, FSMs, and data structures: 


MC_ALLOCATE_PROC page 5.2-21 
MC_CONFIRM_PROC page 5.2-21 
MC_CONFIRMED_PROC page 5.2-22 
MC_DEALLOCATE_PROC page 5.2-23 
MC_FLUSH_PROC page 5.2-23 
MC_GET_ATTRIBUTES_ PROC page 5.2-24¢ 
MC_POST_ON_RECEIPT_PROC page 5.2-25 
MC_PREPARE_TO_RECEIVE_PROC page 5.2-26 
MC_RECEIVE_AND_WAIT_PROC page 5.2-27 
MC_REQUEST_TO_SEND_PROC page 5.2-37 
MC_SEND_DATA_PROC page 5.2-38 
MC_SEND_ERROR_PROC page 5.2-40 
MC_TEST_PROC page 5.2-28 


Select based on the mapped conversation verb (issued by the TP): 
When MC_ALLOCATE 
Call MC_ALLOCATE_PROC (page 5.2-21). 
When MC_CONFIRM | 
Call MC_CONFIRM PROC (page 5.2-21). 
When MC_CONFIRMED 
- Call MC_CONFIRMED_PROC (page 5.2-22). 
When MC_DEALLOCATE 
Call MC_DEALLOCATE_PROC (page 5.2-23). 
When MC_FLUSH 
CALL MC_FLUSH_ PROC (page 5.2-23). 
When MC_GET_ATTRIBUTES | 
Call MC_GET_ATTRIBUTES PROC (page 5.2-24). 
When MC_POST_ON_RECEIPT 
Call MC_POST_ON_RECEIPT_PROC (page 5.2-25). 
When MC_PREPARE_TO_RECEIVE 
Call MC_PREPARE_TO_RECEIVE_PROC (page 5.2-26). 
When MC_RECEIVE_AND_WAIT 
Call MC_RECEIVE_AND WAIT PROC (page 5.2-27). 
When MC_REQUEST_TO_SEND 
Call MC_REQUEST_TO SEND PROC (page 5.2-37). 
When MC_SEND_DATA 
Call MC_SEND_DATA_PROC (page 5.2-38). 
When MC_SEND_ERROR 
Call MC_SEND_ERROR_PROC (page 5.2-40). 
When MC_TEST 
Call MC_TEST_PROC (page 5.2-28). 
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MC_ALLOCATE_PROC 
C MC_ALLOCATE_PROC 
FUNCTION: This procedure handles the allocation of mapped conversations. 


INPUT: 


OUTPUT: A return code as described in SNA Transaction Programmer's Reference Manual 
for LU Type 6.2. 


of this RCB. 


The SNASVCMG mode name is not allowed at the mapped conversation protocol 
boundary. 


A return code on ALLOCATE of PARAMETER_ERROR» PROGRAM_PARAMETER_CHECK, or 
UNSUCCESSFUL indicates that no resource has been allocated (and, therefore, no 
RCB has been created). When the ALLOCATE returns a RETURN_CODE value of OK or 
ALLOCATION_ERROR, an RCB has been created. 


fo. 
z . Referenced procedures, FSMs, and data structures: 
a ALLOCATE_PROC page 5.1-11 
RCB page A-6 


If the transaction program supports mapped conversations and the mode name is 
not SNASVCMG (See Note 1) then 
Call ALLOCATE_PROC(verb parameters) (Chapter 5.0) to issue an ALLOCATE verb with 
the MC_ALLOCATE verb parameters and specifying that the conversation type is mapped. 
Set the MC_ALLOCATE parameters to the values returned by the ALLOCATE verb. 


Else (allocation of a conversation is not allowed) 
Set RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


MC_CONFIRM_PROC 


FUNCTION: This procedure processes MC_CONFIRM verbs. 


INPUT : 


for LU Type 6.2.) 
C, OUTPUT : A return code as described in SNA Transaction Programmer's Reference Manual 
for LU Type 6.2. 
program while processing a CONFIRM verb, this request is also indicated to the 
local TP. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_CONFIRM verb. A_ state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the CONFIRM verb. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing the necessary RECEIVE_AND_WAIT verbs. A 
request to send by the remote TP may be indicated by one of these 
RECEIVE _AND_WAIT verbs, as well as by the CONFIRM verb. In either case, the 
indication is passed to the local TP. 


Referenced procedures, FSMs, and data structures: 


CONFIRM_PROC page 5.1-12 
PS SPS page 5.3-35 
i, RCVD_SVC_ERROR_PURGING page 5.2-42 
UPM_MAPPER page 5.2-46 
/ RCB page A-6 
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MC_CONFIRM_PROC 


Call CONFIRM_PROC(CONFIRM)(page 5.1-12) to issue a CONFIRM verb with . 
the MC_CONFIRM verb parameters. (~ 
Set the MC_CONFIRM parameters and return code to the values returned by the CONFIRM verb. oe 


Select based on the return code copied into MC_CONFIRM: 
When OK : 
Call UPM_MAPPER (page 5.2-46) to record a positive confirmation. 
When PROG_ERROR_PURGING 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code from CONFIRM. 
When DEALLOCATE_ABEND_PROG 
Set RETURN_CODE to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set the RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When BACKED_OUT 
Call PS_SPS (sync point manager, Chapter 5.3). 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to 
get and process error data from the remote TP. 
Set RETURN_CODE to the value returned by RCVD_SVC_ERROR_PURGING. 
If a request to send has been received from the remote TP and not 
indicated on a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, MC_SEND_DATA, or - 
MC_SEND_ERROR verb then + 
Return a request to send received indication to the local TP. é 


MC_CONFIRMED_PROC 


FUNCTION: This procedure processes MC_CONFIRMED verbs. 


INPUT: MC_CONFIRMED verb parameters (See SNA Transaction Programmer's Reference Manu- 
al for LU Type 6.2.) 


NOTE : PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_CONFIRMED. A state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the CONFIRMED verb. 


Referenced procedures, FSMs, and data structures: 
CONFIRMED_PROC page 5.1-14 
Call CONFIRMED_PROC( CONFIRMED ){(page 5.1-14) to issue a CONFIRMED verb with 


the MC_CONFIRMED verb parameters. yor 
Set the MC_CONFIRM return code to the value returned by the CONFIRMED verb. 
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MC_DEALLOCATE_ PROC 


( Me MC_DEALLOCATE_PROC 


FUNCTION: This procedure handles the deallocation of mapped conversation resources. 


INPUT: MC DEALLOCATE verb parameters (See SNA Transaction Programmer's Reference Man- 


ual for LU Type 6.2.) 


OUTPUT: A return code as described in SNA Transaction Programmer's Reference Manual 
for LU Type 6.2. 


NOTE : PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_DEALLOCATE. A_ state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the DEALLOCATE verb. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-46 

RCVD_SVC_ERROR_PURGING page 5.2-42 

DEALLOCATE_PROC page 5.1-15 
A-6 


C : RCB page 
2 


Find the RCB for the conversation identified in the RESOURCE parameter. 
If the deallocation type is ABEND then 
Clear RCB.MC_RECEIVE_BUFFER. 
Call DEALLOCATE_PROC(DEALLOCATE )( page 5.1-15) to issue a DEALLOCATE verb with 
the MC_DEALLOCATE verb parameters, no error data, and deallocation type ABEND_PROG. 
Else 
Call DEALLOCATE_PROC( DEALLOCATE )( page 5.1-15) to issue a DEALLOCATE verb with 
the MC_DEALLOCATE verb parameters, no error data, and deallocation type specified. 
Set the MC_DEALLOCATE parameters and return code to the values returned by the DEALLOCATE verb. 


x Select based on the return code copied into MC_DEALLOCATE: 
% When PROG_ERROR_PURGING 
/ Set RETURN_CODE to the code returned by DEALLOCATE. 
= Call UPM_MAPPER (page 5.2-46) to record a 
remotely detected error of the type indicated by the return code 
from the DEALLOCATE verb. 
When DEALLOCATE_ABEND_PROG 
Set RETURN_CODE to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42). 


MC_FLUSH_PROC 


FUNCTION: This procedure processes MC_FLUSH verbs. 


INPUT: MC_FLUSH verb parameters (See SNA Transaction Programmer's Reference Manual 
for LU Type 6.2.) 


NOTE: PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_FLUSH. A state check is performed by PS.CONV (Chapter 
5.1) during its processing of the FLUSH verb. 


Referenced procedures, FSMs, and data structures: 
FLUSH_PROC | page 5.1-16 


Call FLUSH_PROC( FLUSH )(page 5.1-16) to issue a FLUSH verb with 


* the MC_FLUSH verb parameters. 
| Set the MC_FLUSH return code to the value returned by the FLUSH verb. 
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MC_GET_ATTRIBUTES_PROC 
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MC_GET_ATTRIBUTES_PROC 


FUNCTION: This procedure handles requests from the transaction program for information 
about a mapped conversation. 


INPUT : 


OUTPUT : 


PS.MC places the 
appropriate fields in the MC_GET_ATTRIBUTES and returns control to the trans- 
action program. 


Referenced procedures, FSMs, and data structures: 
GET_ATTRIBUTES_PROC page 5.1-17 


Find the RCB for the conversation identified in the RESOURCE parameter. 

Call GET_ATTRIBUTES_PROC(GET_ATTRIBUTES }(page 5.1-17) to issue a 
GET_ATTRIBUTES verb with the MC_GET_ATTRIBUTES verb parameters. 

Set the MC_GET_ATTRIBUTES parameters and return code to the values returned 
by the GET_ATTRIBUTES verb, to the TP, such as the fully qualified LU names 
of both LUs of the conversation, the mode name, synchronization level, 
security profile, and security user ID. 
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MC_POST_ON_RECEIPT_PROC 


MC_POST_ON_RECEIPT_PROC 


FUNCTION: 


INPUT: 


OUTPUT: 


NOTES: 1. 


This procedure processes MC_POST_ON_RECEIPT verbs. 


If the MC_RECEIVE_BUFFER is empty when the MC_POST_ON_RECEIPT is issued, PS.MC 
issues a POST_ON_RECEIPT verb. Otherwise,» no POST_ON_RECEIPT is necessary 
(see below). 


If the MC_RECEIVE_ BUFFER is not empty, the transaction program has,» prior to 
issuing the current MC_POST_ON_RECEIPT, issued one or more MC_POST_ON_RECEIPTs 
followed by one or more MC_TESTs. The MC_TEST processing caused PS.MC to 
receive data (via a RECEIVE_AND_WAIT) from PS.CONV (Chapter 5.1) and PS.MC has 
stored that data in the MC_RECEIVE_ BUFFER. See "MC_TEST_PROC" on page 5.2-11 
for a discussion of MC_TEST. 


If the information stored in the MC_RECEIVE_BUFFER indicates that a complete 
Application Data or User Control Data GDS variable has been received (and that 
the data in that variable has been mapped), then PS.MC has already informed 
the transaction program via the RETURN_CODE on a previous MC_TEST that posting 
has been satisfied. The transaction program, however, has issued another 
MC_POST_ON_RECEIPT (after having issued an MC_TEST on which was” returned a 
return code of OK--DATA). PS.MC remembers the fact that an MC_POST_ON_RECEIPT 
has been issued, in case the transaction program issues another MC_TEST,; but 
does not issue a POST_ON_RECEIPT to PS.CONV. 


If the data stored in the MC_RECEIVE_BUFFER is not complete (1.e., a Map Name 
GDS variable, but no data, has been received; or part, but not all, of the 
data in an Application or FMH Data GDS variable has been received), posting is 
still activated. PS.MC, therefore, does not issue a POST_ON_RECEIPT to 
PS.CONV. In this situation, the transaction program has issued one or more 
prior MC_TESTs, all of which have been unsuccessful. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_POST_ON_RECEIPT. This state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the POST_ON_RECEIPT verb, if 
PS.MC issues one. As described above, there are certain situations in which 


‘"PS.MC receives an MC_POST_ON_RECEIPT from the transaction program but does not 


issue a POST_ON_RECEIPT to PS.CONV. In these situations, however, the 
MC_RECEIVE_BUFFER in the RCB is not empty. This indicates that the conversa- 
tion is in RECEIVE state and therefore the MC_POST_ON_RECEIPT is valid at the 
present time. 


Referenced procedures, FSMs, and data structures: 
POST_ON_RECEIPT_PROC page 5.1-17 


RCB 


page A-6 


If the RCB.MC_RECEIVE_BUFFER for the current conversation is empty then 
Call POST_ON_RECEIPT_PROC(POST_ON_RECEIPT) (page 5.1-17) on this conversation, 


specifying 


the maximum length of the data to be received before posting,» 


and that posting should be done after receiving a complete logical record. 
Set the MC_POST_ON_RECEIPT parameters and return code to the values returned by the 
POST_ON_RECEIPT verb. 
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MC_PREPARE_TO_RECEIVE_PROC “ 


FUNCTION: This procedure processes MC_PREPARE_TO_RECEIVE verbs. 


PS.MC issues a PREPARE_TO_RECEIVE verb against the resource specified in the 
MC_PREPARE_TO_RECEIVE. It sets the return code _ field in the 
MC_PREPARE_TO_RECEIVE based upon the value returned in the PREPARE_TO_RECEIVE. 
Some return codes, such as OK, are placed in the MC_PREPARE_TO_RECEIVE 
unchanged. Others, such as DEALLOCATE_ABEND_PROG, are transformed to another 
value before being placed in the MC_PREPARE_TO_RECEIVE. In addition, some 
return codes cause PS.MC to perform further processing. For example, when 
PS.MC receives a return code of PROG_ERROR_PURGING to its PREPARE_TO_RECEIVE, 
it invokes the mapper to inform that procedure that an error was detected by 
the partner transaction program. (See "Mapper Invocation" on page 5.2-9. ) 
When a return code of SVC_ERROR_PURGING is received, PS.MC performs the proc- 
essing necessary to determine what type of service error the PS.MC component 
at the partner LU encountered. A return code reflecting the type of error is 
returned to the local transaction program in the MC_PREPARE_TO_RECEIVE. (See 
"Processing of a Service Error Detected by Partner LU" on page 5.2-17.) 


INPUT : 


OUTPUT: PS.MC issues a PREPARE_TO_RECEIVE verb and sets the return code field in the 
MC_PREPARE_TO_RECEIVE based upon the corresponding field in the PRE- 
PARE_TO_RECEIVE. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_PREPARE_TO_RECEIVE. This state check 1s performed by 
PS.CONV (Chapter 5.1) during its processing of the PREPARE_TO_RECEIVE verb. 


Referenced procedures, FSMs, and data structures: 
UPM_MAPPER page 5.2-46 @ 
PREPARE_TO_RECEIVE PROC page 5.1-18 ~~ 
RCVD_SVC_ERROR_PURGING page 5.2-42 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 

Call PREPARE_TO_RECEIVE_PROC( PREPARE_TO_RECEIVE )(page 5.1-18) to issue a 
PREPARE_TO_RECEIVE verb with the MC_PREPARE_TO_RECEIVE verb parameters. 

Set the MC_PREPARE_TO_RECEIVE parameters and return code to the values 
returned by the PREPARE_TO_RECEIVE verb. 


Select based on the return code copied into MC_PREPARE_TO_RECEIVE: 
When (PROG_ERROR_PURGING) aT 
Call the UPM_MAPPER (page 5.2-46) to record C 
the RETURN_CODE for the remotely detected error. 
When (DEALLOCATE_ABEND_PROG ) 
Set RETURN_CODE to DEALLOCATE_ABEND. 
When (DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER) 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When (SVC_ERROR_PURGING) 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to 
do service error processing, specifying the return code and current RCB. 
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MC_RECEIVE_AND_WAIT_PROC 


MC_RECEIVE_AND_WAIT_PROC 


FUNCTION: This procedure processes MC_RECEIVE_AND_WAIT verbs. 


PS.MC first determines the status of the MC_RECEIVE BUFFER. Processing of the 
MC_RECEIVE_AND_WAIT continues based upon the status of the buffer. 


The MC_RECEIVE_BUFFER contains any information that has been received from 
PS.CONV (Chapter 5.1) but has not yet been passed to the transaction program. 
It is in one of the following states: (1) the buffer is empty, (2) the buffer 
contains information, but the information is incomplete and more has_ to be 
received before it can be passed to the transaction program, or (3) the buffer 
contains information that is complete and ready to be passed to the trans- 
action program. 


If the MC_RECEIVE_BUFFER is not empty, the transaction program has issued one 
or more prior MC_TEST verbs. The processing that PS.MC performed as a result 
of the MC_TEST(s) involved receiving data from PS.CONV. It is the data that 
resulted from the MC_TEST(s) that is stored in the MC_RECEIVE BUFFER. 


INPUT : 


OUTPUT : Fields in the MC_RECEIVE_AND_WAIT are set based upon the type of information 
being returned to the transaction program. 


If the MC_RECEIVE_ BUFFER is empty or contains incomplete data, this procedure 
causes one or more RECEIVE _AND_WAIT verbs to be issued to PS.CONV. PS.MC con- 
tinues to issue RECEIVE_AND_WAITs until it has a complete piece of informa- 
tion. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_RECEIVE_AND_WAIT. This state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the RECEIVE_AND_WAIT verb, if 
PS.MC issues one. If the MC_RECEIVE_BUFFER already contains complete informa- 
tion ready to be passed to the transaction program, PS.MC does not issue a 
RECEIVE_AND_WAIT. However, the fact that the MC_RECEIVE_BUFFER is not empty 
indicates that the mapped conversation is in RECEIVE state and that the 
MC_RECEIVE_AND_WAIT is valid at the present time. 


RECEIVE_INFO_ PROC on page 5.2-30 issues a RECEIVE_AND_WAIT to PS.CONV and 
causes processing of the information returned in the RECEIVE_AND_WAIT to 
occur. It is possible that when control is returned from this procedure, the 
MC_RECEIVE_BUFFER is empty, even though data was returned in the 
RECEIVE_AND_WAIT. This is the case when PS.MC detects an error in’ the data 
(e.g.» the data specified a function not supported). Nothing is placed in the 
buffer during this invocation of RECEIVE_INFO_PROC. For more details, see 
"Service Errors Detected in Received Data" on page 5.2-14. 


Referenced procedures, FSMs, and data structures: 
RECEIVE _INFO_PROC page 5.2-30 
RCB page A-6 


If the RCB.MC_RECEIVE_BUFFER contains a null entry, map name, data-continued 
indicator, or map name and data-continued indicator then 
Call RECEIVE_INFO_PROC(RCB) (page 5.2-30) 
to issue a RECEIVE_AND_ WAIT verb. 
If the RCB.MC_RECEIVE_BUFFER does not contain a null entry, or contains 
mapped data or a return code entry then 
Select based on the contents of the RCB.MC_RECEIVE_BUFFER: 
When the buffer element contains a WHAT_RECEIVED indicator 
Put the WHAT_RECEIVED indicator in the MC_RECEIVE_AND_WAIT verb. 
Set RETURN_CODE to OK. 
When the buffer element contains a return code 
Set RETURN_CODE to the buffer return code. 
When the buffer element contains mapped data 
Retrieve the mapped data from the MC_RECEIVE_BUFFER and place the 
amount of data requested by the transaction program into the DATA 
field of the MC_RECEIVE_AND_WAIT. Indicate whether data was complete 
or truncated, and indicate that FMH data, if present, was complete. 
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Clear the MC_RECEIVE BUFFER for the current RCB. 

If a request to send has been received from the remote TP and not returned on 

a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, MC_SEND_DATA, or MC_SEND_ERROR verb then 
Return a request-to-send-received indication to the local TP on the verb. 


MC_TEST_PROC 


FUNCTION: 


INPUT ;: 


OUTPUT : 


NOTES: 1. 


This procedure processes MC_TEST verbs. 
MC_TEST 


PS.MC sets the RETURN_CODE field in the MC_TEST based upon the outcome of the 
specified test. Depending upon the type of test specified and the information 
contained in the RCB, PS.MC may issue basic conversation verbs that are proc- 
essed by PS.CONV. RCB.MC_RECEIVE_ BUFFER, or a return code obtained by calling 
TEST_PROC (page 5.1-26). 


If RCB.MC_RECEIVE_ BUFFER is not empty when a return code of OK--NOT_DATA is 
received, the partner LU has committed a protocol violation. For example, the 
partner LU has sent data with an indication that the data is continued in the 
next logical record, but instead of sending the remaining data, the partner LU 
allowed a SEND indicator to flow. 


RCB.MC_RECEIVE_BUFFER may be empty at this point. This occurs’ when the TEST 
verb just issued returns OK--DATA but an error is detected in the data by 
RECEIVE_INFO_PROC (page 5.2-30). For more details, see “Service Errors 
Detected in Received Data" on page 5.2-14. 


An INDICATOR element cannot appear in RCB.MC_RECEIVE_BUFFER here. If the TEST 
verb just issued returns OK--NOT_DATA, the conversation indicator that caused 
this return code remains in PS.CONV's buffer. PS.MC does not issue a 
RECEIVE_AND_WAIT to PS.CONV to get the indicator until the transaction program 
issues an MC_RECEIVE_AND_WAIT. 


The RCB.MC_RECEIVE_ BUFFER contains data ready to be returned to the trans- 
action ‘program as a_- result of one or more prior calls to MC_TEST 
(TEST=POSTED). . 


Referenced procedures, FSMs, and data structures: 


TEST_PROC page 5.1-26 
RECEIVE_INFO_PROC page 5.2-30 
POST_ON_RECEIPT_PROC page 5.1-17 
PROTOCOL_ERROR_PROC page 5.2-47 
PROCESS_ERROR_OR_FAILURE_RC page 5.2-31 
RCB page A~-6 
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MC_TEST_PROC 


Select based on the specified type of test: 
When POSTED 
If RCB.MC_RECEIVE BUFFER is empty or contains a map name or unmapped data then 
Call TEST_PROC (page 5.1-26) to determine whether the current 
conversation has been posted indicating that data, status, or a 
request for confirmation has been received from the remote TP. 
Select based on the return code from TEST_PROC: 
When OK--DATA 
Call RECEIVE_INFO_PROC (page 5.2-30) to receive 
the data and place it in RCB.MC_RECEIVE_BUFFER. 
When OK--NOT_DATA 
If RCB.MC_RECEIVE_BUFFER is empty then 
Put the RETURN_CODE from TEST in RCB.MC_ RECEIVE _BUFFER. 
Else (optional check when receiving data; See Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE_ BUFFER with the 
RETURN_CODE RESOURCE_FAILURE_NO_RETRY. 
When POSTING_NOT_ACTIVE or UNSUCCESSFUL 
Put the RETURN_CODE from TEST in RCB.MC_RECEIVE_BUFFER. 
Otherwise 
Call PROCESS _ERROR_OR_FAILURE_RC (page 5.2-31) 
to process the RETURN_CODE from TEST. 
If RCB.MC_RECEIVE BUFFER is empty or contains a map name or 
unmapped data (See Note 2) then 
Set RETURN_CODE to UNSUCCESSFUL. 
Call POST_ON_RECEIPT_PROC( POST_ON_RECEIPT }(page 5.1-17) to issue a 
POST_ON_RECEIPT verb specifying posting when a complete or truncated logical 
record 1s received. 


Else 
Select based on the type of information in RCB.MC_RECEIVED_BUFFER 
(See Note 3): 

When it 1s mapped data 
Set RETURN_CODE to OK--DATA. 

When it is a RETURN_CODE 
Set RETURN_CODE to that in RCB.MC_RECEIVE BUFFER. 
Clear RCB.MC_RECEIVE_BUFFER. 

Else 


If there is mapped data in RCB.MC_RECEIVE_BUFFER and the local 
TP has issued a MC_POST_ON_RECEIPT verb since this data was 
mapped then (See Note 4) 

Set RETURN_CODE to OK--DATA. 
Else 
Set RETURN_CODE to POSTING NOT ACTIVE. 


When REQUEST_TO_SEND_RECEIVED 

If a request to send has been received from the remote TP and not 
yet returned to the local TP then 

Return a request-to-send-received indication to the local TP. 
Else 

Call TEST_PROC (page 5.1-26) to determine whether 

a request to send has been received from the remote TP and is 

being held by PS.CONV. 

If a request to send was held by PS.CONV then 

Return a request-to-send-received indication to the local TP. 
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RECEIVE_INFO_PROC u 


FUNCTION: The purpose of this procedure is to receive information from PS.CONV (Chapter 
5.1} and to place that information in the MC_RECEIVE BUFFER. 


This procedure issues a RECEIVE_AND_WAIT for the mapped conversation corre- 
sponding to the passed _ RCB. PS.MC continues the processing of the 
RECEIVE _AND_WAIT in other procedures, depending upon the return code carried 
in the RECEIVE_AND_WAIT. 


INPUT: The RCB corresponding to the mapped conversation specified in the TRANS- 
ACTION_PGM_VERB currently being processed 


OUTPUT: See the procedures called for the specific outputs. 


Referenced procedures, FSMs, and data structures: 
PROCESS_ERROR_OR_FAILURE_RC page 5 
PROTOCOL_ERROR_PROC page 5 
PROCESS_DATA_COMPLETE page 5. 
PROCESS _DATA_INCOMPLETE page 5 
UPM_MAPPER page 5 
RCB page A 


Issue a basic RECEIVE_AND_WAIT verb for a complete logical record 
specifying the maximum length of the data. 
If a request to send data was received from the remote TP then 
Save an indication of the request to be returned later. 
If the RECEIVE_AND_WAIT was successful then 
Select based on the WHAT_RECEIVED field on the RECEIVE_AND_WAIT verb: 
When the data received is complete 
Call PROCESS_DATA_COMPLETE(RCB, RECEIVE _AND_WAIT) (page 5.2-33). 
When the data received is incomplete 
Call PROCESS DATA_INCOMPLETE(RCB} (page 5.2-36). a 
When the RCB.MC_RECEIVE BUFFER is empty ( : 
Put the WHAT_RECEIVED indicator in the MC_RECEIVE_BUFFER See 
of the current RCB. 
Call the UPM_MAPPER (page 5.2-46) to save an 
indication that the end of the logical message was received. 
When the RCB.MC_RECEIVE_BUFFER is not empty, but does not contain data, 
Clear the MC_RECEIVE_BUFFER in the current RCB. 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RESOURCE_FAILURE_NO_RETRY RETURN_CODE in the 
MC_RECEIVE BUFFER of the current RCB. 
Else 
Call PROCESS_ERROR_OR_FAILURE_RC (page 5.2-31) 7 ~ 


Ps 
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Cm 


FUNCTION: This procedure is invoked after PS.MC has issued a RECEIVE_AND_WAIT to which 
has been returned a RETURN_CODE value other than OK. Processing of the return 
code continues in other procedures, depending upon the return code. 


INPUT: The RCB' corresponding to the conversation specified in the verb being proc- 
essed, and the RECEIVE_AND_WAIT return code to be processed 


OUTPUT: — A return code value is placed in RCB.MC_RECEIVE_BUFFER. 


NOTES: . Certain return codes are invalid if RCB.MC_RECEIVE_BUFFER is not empty» and, 
if received at such a time, indicate that the partner LU has committed a pro- 
tocol violation. Depending upon the return code, PS.MC may end the mapped 
conversation. ‘ | 


A return code on RECEIVE _AND_WAIT of ALLOCATION_ERROR cannot occur if prior 
information has been received on the specified mapped conversation. 


pr, . A return code on RECEIVE_AND WAIT of PROG_ERROR_PURGING or SVC_ERROR_PURGING 

( . cannot occur if MC_RECEIVE_BUFFER is not empty. It can occur only if the 

cL ne RECEIVE _AND_WAIT was issued by PS.MC while the mapped conversation was in SEND 
state. (The partner transaction program or LU that issued the *_ERROR_PURGING 
information was in RECEIVE state.) Since the mapped conversation was in the 
SEND state locally, no information can be in RCB.MC_RECEIVE_ BUFFER. 


The return codes that reference this note can be received at any time and are 
valid regardless of the status of RCB.MC_RECEIVE_BUFFER. 


A return code of *_ERROR_TRUNC cannot be received on the RECEIVE_AND_WAIT 
issued by this’ procedure because it can only be received following a 
RECEIVE_AND_WAIT ih which a WHAT_RECEIVED value of DATA_INCOMPLETE is 
returned. (This procedure is not invoked after a DATA_INCOMPLETE indicator 


C has been received. ) 
} 


Referenced procedures, FSMs, and data structures: 


PS SPS page 5.3-35 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC page 5.2-41 
RCVD_SVC_ERROR_PURGING page 5.2-42 
UPM_MAPPER page 5.2-4%6 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB | page A-6 


Select based on the RECEIVE_AND_WAIT return code being processed: 
—— When ALLOCATION_ERROR (See Note 2), PROGRAM_STATE_CHECK 
, Put the RETURN_CODE in RCB.MC_RECEIVE_ BUFFER. 
= When DEALLOCATE_NORMAL 
If RCB.MC_RECEIVE_BUFFER is empty then 
Put the RETURN_CODE in RCB.MC_RECEIVE_BUFFER. 
Else (optional check when receiving data; See Note 1) 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the 
RETURN_CODE value RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. 
When DEALLOCATE_ABEND_PROG 
If RCB.MC_RECEIVE_ BUFFER is empty then. 
Put the RETURN_CODE DEALLOCATE_ABEND in RCB.MC_RECEIVE_BUFFER. 
Else (optional check when receiving data; See Note 1 ) 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the 
RETURN_CODE RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. 
When PROG_ERROR_PURGING (See Note 3) 
Put the RETURN_CODE in RCB.MC_RECEIVE BUFFER. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code parameter. 
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When PROG_ERROR_NO_TRUNC 
If RCB.MC_RECEIVE_BUFFER is empty then 
Put the RETURN_CODE in RCB.MC_RECEIVE_BUFFER. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the RETURN_CODE. 
Else (optional check when receiving data; See Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the 
RETURN_CODE RESOURCE_FAILURE_NO_RETRY. 
When DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER (See Note 4) 
Replace the contents of RCB.MC_RECEIVE BUFFER by the 
RETURN_CODE RESOURCE_FAILURE_NO_RETRY. 
When RESOURCE_FAILURE_RETRY, RESOURCE_FAILURE_NO_RETRY (See Note 4) 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the RETURN_CODE. 
When BACKED_OUT 
If RCB.MC_RECEIVE BUFFER is empty then 
Call PS_SPS (sync point manager, Chapter 5.3). 
Put the RETURN_CODE in RCB.MC_RECEIVE BUFFER. 
Else (optional check when receiving data; See Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the 
RETURN_CODE RESOURCE _FAILURE_NO_RETRY. 
When SVC_ERROR_NO_TRUNC (See Note 4) 
Clear the RCB.MC_RECEIVE_BUFFER. 
Call RCVD_SVC_ERROR_TRUNC_NO_TRUNC (page 5.2-41) 
to process the RETURN_CODE. 
When SVC_ERROR_PURGING (See Note 3) 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to get 
and process error data from the partner LU. 
Put the RETURN_CODE in RCB.MC_RECEIVE_BUFFER. 
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PROCESS DATA_COMPLETE 


FUNCTION: This procedure is invoked when PS.MC issues a RECEIVE_AND_WAIT and a value of 
DATA_COMPLETE is returned in the WHAT_RECEIVED field of the RECEIVE_AND_WAIT. 
The purpose of this procedure is to process the received data. 


The data received in the RECEIVE _AND_WAIT is a logical record. It may be the 
first or only logical record ina GDS variable. Alternatively, it may be a 
subsequent logical record in a GDS variable containing multiple logical 
records. A subsequent logical record does not carry a GDS ID field. 


If the MC_RECEIVE_BUFFER is empty, the data in the RECEIVE_AND_ WAIT is the 
initial or only logical record in a GDS variable. This procedure checks the 
GDS ID in the logical record and calls the appropriate procedure to process 
the data carried in the DATA field of the logical record. 


If the MC_RECEIVE_BUFFER contains a map name but no data, the data in the 
RECEIVE_AND_WAIT is again the initial or only logical record inaé_é GDS vari- 


able. The GDS variable following a Map Name GDS variable has to contain 


“a application or user control data. 

Sa If the MC_RECEIVE_BUFFER contains incomplete data or a map name and incomplete 
data (1.e., the last logical record in a GDS variable that contains multiple 
logical records has not been received), the appropriate procedure is called to 
add the data carried in the DATA field of the subsequent logical record to the 
data already contained in the MC_RECEIVE_BUFFER. If the subsequent logical 
record is the last logical record in the GDS variable, additional processing 
1s performed. 

The RCB associated with the mapped conversation specified in the current verb 
issued by the’ transaction program and the RECEIVE_AND_WAIT (issued by PS.MC) 
that contains the data to be processed 
| OUTPUT: Depending upon the data received, the MC_RECEIVE_BUFFER may be updated. See 
wy the procedures called for specific outputs. | 
Referenced procedures, FSMs, and data structures: 
SEND_SVC_ERROR_PURGING page 5.2-45 
PROTOCOL_ERROR_PROC page 5.2-47 
PROCESS_MAPPER_RETURN_CODE page 5.2-35 
UPM_MAPPER page 5.2-46 
RCB page A-6 
If the MC_RECEIVE BUFFER for the current conversation is empty (no map name) then 
—— Select based on the type of GDS variable in the passed data (first record): 
4 When a Map Name GDS variable 
wif If the LU receiving the map name supports mapping and the TP for this 


conversation supports mapping then 
Put the unmapped map name in the MC_RECEIVE BUFFER (data incomplete). 
Else (the LU or TP doesn't support mapping) | 
Call SEND _SVC_ERROR_PURGING (page 5.2-45) to 
handle the invalid map name and mapping request. 
When an Application Data GDS variable 
Put the passed unmapped data and an indication that FM headers are 
not included in the data in the MC_RECEIVE_BUFFER. | 
If data is not continued in the next logical record (only one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data, specifying that FMH data is not included. 
(No mapping will occur if no map name is found. ) 
Call PROCESS MAPPER_RETURN_CODE (page 5.2-35). 
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When a User Control Data GDS variable 
If the LU for the current conversation supports FMH data and 
the TP for the current conversation supports FMH data then 
Put the passed unmapped data and an indication that FM headers are 
included in the data in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next record (one logical record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to get the map name and to map the received data, specifying that FMH 
data is included. (No mapping will occur if no map name is found. ) 
Call PROCESS MAPPER_RETURN_CODE(RCB) (page 5.2-35). 
Else (the LU or TP doesn't Support FMH-data) 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
to perform service error purging, and to notify the partner LU. 
When a Null Structured Data GDS variable 
Do nothing. 
When an Error Data GDS variable, optionally 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code in the MC_RECEIVE_BUFFER of the current RCB. 
When the GDS ID is invalid 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) to 
handle the invalid GDS ID (no such variable type). 
Else (the MC_RECEIVE_BUFFER is not empty) | 
If the buffer element in the MC_RECEIVE_BUFFER is a map name then 
Select based on the contents of the passed RECEIVE_AND_WAIT data: 
When the GDS ID indicates an Application Data variable 
Add the passed data and an indication that FM headers are 
not included in the data to the unmapped map name in the 
MC_RECEIVE_BUFFER. 
If the data is not continued in the next record (one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data in the MC_RECEIVE_BUFFER. 
Call PROCESS_MAPPER_RETURN_CODE (page 5.2-35). 
When the GDS ID indicates a User Control Data GDS variable 
If the LU for the current conversation supports FMH data and 
the TP for the current conversation supports FMH data then 
Add the passed data and an indication that FM headers are included 
in the data to the unmapped map name in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next record (only one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data in the MC_RECEIVE_BUFFER. 
Call PROCESS_MAPPER_RETURN_CODE (page 5.2-35). 
Else (the LU or TP doesn't support FMH data) 
Call SEND _SVC_ERROR_PURGING (page 5.2-45) 
to perform service error purging,» and to notify the partner LU. 
When the GDS ID is invalid for a map name buffer element, optionally 
Purge the MC_RECEIVE_BUFFER for the current RCB. 
CALL PROTOCOL_ERROR_PROC (page 5.2-47) to 
deallocate the conversation. 
Put the return code in the MC_RECEIVE_ BUFFER of the current RCB. 
Else (the buffer element indicates continued data» with or without a map name) 
Add the passed data to the data contained in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next logical record then 
Call the UPM_MAPPER (page 5.2-46) to map the contents 
of the MC_RECEIVE_BUFFER (a complete variable), specifying the map 
name, if any» and that FM header data is included. 
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PROCESS_MAPPER_RETURN_CODE 


C. 


FUNCTION: This procedure determines whether the mapper was successful in mapping data. 
It is invoked after the mapper has been called to process data received from 
-the partner transaction program. 


The RCB corresponding to the mapped conversation over which the data _ to be 
mapped flowed; anda structure containing information that is both supplied 
to, and returned from, the mapper 


OUTPUT: If the mapper was able to successfully map the received data, the mapped data, 
along with a locally Known map name provided by the mapper and an indication 
of the format of the mapped data, is placed in the MC_RECEIVE_BUFFER. If map- 
ping was unsuccessful, PS.MC performs service error purging processing to 
notify the partner LU that the received data could not be mapped. (See “Serv- 
ice Errors Detected in Received Data" on page 5.2-14.) 


If the mapper was successful in mapping the received data, it always provides 
to PS.MC a protocol boundary map name Known to the local transaction program. 
The map name is supplied by the mapper even when it was invoked without a map 
name (in which case, the mapper uses a previously received map name). If map- 
ping is off, the mapper supplies a null map name, which is passed _ to the 
transaction program. 


a 


If the mapper encountered an error in mapping the data, it provides to PS.MC 
the map name, Known to the remote LU, that was in effect when the mapper was 
invoked. PS.MC places the map name in an Error Data GDS variable, which is 
sent to the partner LU to notify it of the mapping failure. 


A return code of MAP_NOT_FOUND cannot be returned from the mapper if the 

mapper is invoked without a map name. If the mapper is invoked without a map 

name, it determines that 1% is to use a previously received map name. If the 

map name had been unknown to the mapper, this fact would have been discovered 
C as a result of the earlier mapper invocation. 


Referenced procedures, FSMs, and data structures: 
SEND_SVC_ERROR_PURGING page 5.2-45 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB° page A-6 


Select based on the RETURN_CODE from the mapper: 
When mapping was successful 
Put the mapped map name, an indication that FM headers are included 
in the data, and the mapped data in the MC_RECEIVE_BUFFER. 
a When mapping failed to execute successfully 
a ' Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
Ly specifying the current RCB and the error type. 
When the provided map name was not found 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
specifying the current RCB and the error type. 
When the map name was a duplicate (optional processing for receive only) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) to 
deallocate the current conversation. 
Put a duplicate map name RETURN_CODE in the current MC_RECEIVE_BUFFER. 
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PROCESS_DATA_INCOMPLETE — 


FUNCTION: 


INPUT : 


OUTPUT : 


This procedure is invoked when PS.MC issues a RECEIVE_AND_WAIT as a result of 
a mapped conversation verb issued by the transaction program. PS.MC has exam- 
ined the value returned in the WHAT_RECEIVED field of the RECEIVE_AND WAIT, 
determined that the value received is DATA_INCOMPLETE, and has discarded the 
incomplete logical record returned in the RECEIVE_AND_WAIT. 


This procedure purges the MC_RECEIVE_BUFFER of any data that has been received 
via one or more prior RECEIVE_AND_WAITs. It then issues a RECEIVE_AND_WAIT to 
determine the reason for the logical record being truncated. Processing con- 
tinues based upon the RETURN_CODE value received in the RECEIVE_AND_WAIT. 


The RCB corresponding to the resource specified in the RECEIVE_AND_WAIT in 
which DATA_INCOMPLETE was returned. 


This procedure issues a RECEIVE_AND_WAIT. Depending upon the RETURN_CODE val- 
ue returned on the RECEIVE_AND_WAIT, a return code buffer element may be 
inserted into the MC_RECEIVE_BUFFER. 


RETURN_CODE values of DEALLOCATE_ABEND_PROG, PROG_ERROR_TRUNC, and BACKED_OUT 
following a DATA_INCOMPLETE notification indicate that the partner LU has com- 
mitted a protocol violation by allowing the transaction program to truncate 
data. This should never occur at the mapped conversation protocol boundary. 
The PS.MC at the partner LU is allowed to truncate a logical record with 
SVC_ERROR_TRUNC, for instance; the transaction program is not. 


Referenced procedures, FSMs» and data structures: 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC page 5.2-41 
PROTOCOL_ERROR_PROC . page 5.2-47 
PS_VERB_ROUTER page 5.0-16 
RCB page A-6 


Clear the RCB.MC_RECEIVE_BUFFER. 
Call the PS_VERB_ROUTER (Chapter 5.0) to issue a 

RECEIVE_AND_WAIT verb to get the RETURN_CODE that explains why the 
data was incomplete. 


If a request 


to send data was received from the remote TP then 


Save an indication of the request to be returned later. 
Select based on the RECEIVE_AND_WAIT return code: | 
When the return code is SVC_ERROR_TRUNC 
Call RCVD_SVC_ERROR_TRUNC_NO_TRUNC to do service error processing 
(page 5.2-41). 
When the return code is DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When the RETURN_CODE is RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY 
Put the RETURN_CODE in the MC_RECEIVE_BUFFER of the current RCB. 
When the RETURN_CODE is DEALLOCATE_ABEND_PROG, optionally do the following: 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE BUFFER of the current RCB. 
Log implementation-dependent error data in the system error log. 
When the RETURN_CODE is PROG_ERROR_TRUNC or BACKED_OUT, optionally do the following: 
Call PROTOCOL_ERROR_PROC (page 5.2-47) to deallocate the 
current conversation. 
Put the RETURN_CODE in the MC_RECEIVE_BUFFER of the current RCB. 
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MC_REQUEST_TO_SEND_PROC 


FUNCTION: 


This procedure processes MC_REQUEST_TO_SEND verbs. 


PS.MC issues a REQUEST_TO_SEND verb against the resource specified in the 
MC_REQUEST_TO_SEND and returns control to the transaction program. 


MC_REQUEST_TO_SEND verb parameters. 
PS.MC performs no check to determine if the conversation is in an appropriate 


state to receive an MC_REQUEST_TO_SEND verb. A state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the REQUEST_TO_SEND verb. 


Referenced procedures, FSMs,» and data structures: 
REQUEST_TO_SEND_PROC page 5.1-23 


Call REQUEST_TO_SEND_PROC( REQUEST_TO_SEND)(page 5.1-23) to issue 
a REQUEST_TO_SEND verb with the MC_REQUEST_TO_SEND verb parameters. 
Set the MC_REQUEST_TO_SEND return code to the value returned by the REQUEST_TO_SEND verb. 
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MC_SEND_DATA_PROC 


FUNCTION: 
INPUT : 
OUTPUT : 
NOTES: 1. 
2. 


This procedure processes MC_SEND_DATA verbs. 


This procedure causes the mapper to be invoked. If the mapper is successful 
in mapping the data contained in the MC_SEND_DATA;> or if the mapper determines 
that mapping is not being performed, the output data from the mapper is placed 
in an Application Data or User Control Data GDS variable (the variable may 
contain one or more logical records). The mapper may also return to PS.MC a 
map name that is to be sent to the partner LU, in which case PS.MC also cre- 
ates a Map Name GDS variable that precedes the data GDS variable. This proce- 
dure then issues a SEND_DATA containing the GDS variable(s). | 


PS.MC sets the return code field in the MC_SEND_DATA based upon’ the value 
returned in the SEND_DATA. Some return codes, such as OK, are placed in the 
MC_SEND_DATA unchanged. Others, such as DEALLOCATE_ABEND_PROG, are trans- 
formed to another value before being placed in the MC_SEND_DATA. In addition, 
some return codes cause PS.MC to perform further processing. For example, 
when PS.MC receives a return code of PROG_ERROR_PURGING to its SEND_DATA, it 
invokes the mapper to inform that procedure that the partner transaction pro- 
gram detected an error. (See "Mapper Invocation" on page 5.2-9.) When a 
return code of SVC_ERROR_PURGING is received, PS.MC performs the processing 
necessary to determine what type of service error the PS.MC component at the 
partner LU encountered. A return code reflecting the type of error is 
returned to the local transaction program in the MC_SEND_DATA. (See "Process- 
ing of a Service Error Detected by Partner LU" on page 5.2-17.) 


MC SEND DATA verb parameters (See SNA Transaction Programmer's Reference Man- 
ual for LU Type 6.2.) 

PS.MC issues a SEND_DATA verb. It sets fields in the MC_SEND_DATA based upon 
the corresponding values returned in the SEND_DATA. 


PS.MC performs a check to determine if the conversation is_ in an appropriate 
state to receive an MC_SEND_DATA. This is unlike its processing of most 
mapped conversation verbs, in that PS.MC generally does not perform this state 
check, but instead allows it to be performed by PS.CONV (Chapter 5.1). PS.MC 
performs the state check, rather than deferring it, for the following reasons: 
unlike other verbs, the MC_SEND_DATA causes PS.MC to perform some amount of 
processing before issuing a basic conversation verb. By PS.MC performing the 
state check, any state errors are detected before the processing is performed. 
In addition, if the data provided in the MC_SEND_DATA could not be mapped by 
the mapper procedure, no basic conversation verb is issued; in order to catch 
any state errors, PS.MC has to perform the state check. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing one or more RECEIVE_AND_WAIT verbs. 
REQUEST_TO_SEND_RECEIVED information may be returned on the 
RECEIVE_AND_WAIT(s), and, if this 1s the case, the MC_SEND_DATA is updated to 
reflect this information. 


Referenced procedures > FSMs» and data structures: 


UPM_MAPPER . page 5.2-%6 
RCVD_SVC_ERROR_PURGING page 5.2-42 
PS_SPS page 5.3-35 
SEND_DATA_PROC page 5.1-24 
SEND_BUFFER page 5.2-48 
RCB page A-6 
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; Find the RCB for the resource specified in the MC_SEND_DATA verb. 
% If the resource is ina state to receive data (Chapter 5.1) then 
& Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the data to be sent, specifying the map name and whether or not the data 
contains FM header data (all from the verb). 
Select based on the RETURN_CODE from the mapper: 
When the mapper RETURN_CODE is MAP_NOT_FOUND 
Set the MC_SEND_DATA RETURN_CODE to MAP_NOT_FOUND. 
When the mapper RETURN_CODE is MAP_EXECUTION_FAILURE 
Set the MC_SEND_DATA RETURN_CODE to MAP_EXECUTION_FAILURE. 
Optionally, log implementation-dependent error data in system error log. 
When the mapping was successful 
If a map name was returned from the mapper then 
Create a Map Name GDS variable for the map name and put it in the SEND_BUFFER. 
Create a GDS variable that contains the data passed with the verb, 
which has been successfully mapped. The GDS variable, depending on the 
amount of data, may consist of one logical record or of multiple continued 
logical records. Only the first logical record will carry the GDS ID 
indicating either a User Control Data or an Application Data GDS variable type. 
Put, or add, the data GDS variable in, or to, the SEND_BUFFER. 
Call SEND_DATA_PROC (page 5.1-24) to issue a 
at SEND_DATA verb with the MC_SEND_DATA verb parameters. 
| C Set the MC_SEND_DATA parameters and return code to the values returned 
: by the SEND_DATA verb. 


Select based on the return code copied into MC_SEND_DATA: 
When OK 
Do nothing. 
When DEALLOCATE_ABEND_PROG 
Set RETURN_CODE to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When PROG_ERROR_PURGING 
Call UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
exes: | to notify the mapper of the remotely detected error. 
. When BACKED_OUT 
Call PS SPS (Chapter 5.3). 
i When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING passing the current RCB and the 
SEND_DATA return code (page 5.2-42). 

If a request to send has been received from the remote TP and not 
returned on a prior MC_CONFIRM, MC_RECEIVE_AND WAIT, MC_SEND_DATA, 
or MC_SEND_ERROR verb then 

Return a request-to-send-received indication to the local TP on 
the MC_SEND_DATA verb. 
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MC_SEND_ERROR_PROC 


5.2-40 


MC_SEND_ERROR_PROC 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 1. 


This procedure processes MC_SEND_ERROR verbs. 


MC SEND ERROR verb parameters (See SNA Transaction Programmer's Reference 


A return code indicating the result of the verb execution. An indication that 
a request to send has been received from the remote TP may also be returned. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_SEND_ERROR. A_ state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the SEND_ERROR verb. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing one or more RECEIVE_AND_WAIT verbs. A 
request to send from the remote TP may be returned on a RECEIVE_AND_WAIT and, 
if this is the case, an indication of the request is passed to the local TP. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-46 
RCVD_SVC_ERROR_PURGING page 5.2-42 
PS_SPS page 5.3-35 
SEND_ERROR_PROC page 5.1-25 
RCB page A-6 


Find the RCB for the conversation identified in the RESOURCE parameter. 
Clear RCB.MC_RECEIVE BUFFER. 
Call SEND_ERROR_PROC(SEND_ERROR)( page 5.1-25) to issue a SEND_ERROR 


verb with the 


MC_SEND_ERROR verb parameters. 


Select based on the return code in SEND_ERROR: 


When OK 


Set RETURN_CODE to the value returned on SEND_ERROR. 
If the conversation is in send state (Chapter 5.1) then 
Call UPM_MAPPER (page 5.2-46) to record a locally detected 
error of the type PROG_ERROR_NO_TRUNC. 


Else 


Call UPM_MAPPER (page 5.2-46) to record a locally detected 
error of the type PROG_ERROR_PURGING. 
When PROG_ERROR_PURGING 
Set RETURN_CODE to the value returned on SEND_ERROR. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code from SEND_ERROR. 
When ALLOCATION_ERROR, DEALLOCATE_NORMAL, PROGRAM_STATE_CHECK ,» 
RESOURCE_FAILURE_RETRY» or RESOURCE_FAILURE_NO_RETRY 
Set RETURN_CODE to the value returned on SEND_ERROR. 
When DEALLOCATE_ABEND_PROG 
Set RETURN_CODE to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When BACKED_OUT 
Call PS_SPS (Chapter 5.3). 
Set RETURN_CODE to the value returned on SEND_ERROR. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42). 
Set RETURN_CODE to the value returned on RCVD_SVC_ERROR_PURGING. 


If a request to send has been received from the remote TP and not 
indicated to the local TP on a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, 


MC_SEND_DATA, 


or MC_SEND_ERROR verb then 


Return a request-to-send-received indication to the local TP 
(see SNA Transaction Programmer's Reference Manual for LU Type 6.2). 
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aa 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC 


FUNCTION: 


This procedure is invoked when aéereturn code of SVC_ERROR_TRUNC or 
SVC_ERROR_NO_TRUNC is returned by a RECEIVE_AND_WAIT verb. This return code 
indicates that the partner LU detected a map execution failure while sending 
data. All or only part of the data may have been sent. Any data that was 
received prior to the error is purged. Error information is optionally placed 
in the system error log, but the: local transaction program is not informed of 
the error. 


The RCB associated with the mapped conversation on which the service error was 
detected and the SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC return code 


If the expected Error Data GDS variable is not received, or is received but 
indicates an error condition that is invalid in the present situation, the 
partner LU has committed a protocol violation. If the protocol violation 
occurred as a result of the partner LU allowing the mapped conversation to be 
prematurely ended without having sent the error data, PS.MC simply logs the 
error. Otherwise, PS.MC ends the mapped conversation. In either case, PS.MC 
inserts a return code of RESOURCE_FAILURE_NO_RETRY in RCB.MC_RECEIVE_BUFFER. 


A return code of RESOURCE_FAILURE_RETRY or _NO_RETRY can occur at any time and 
does not indicate that the partner LU committed a protocol violation. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-46 
RECEIVE AND_WAIT_PROC page 5.1-19 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB | page A-6 

ERROR_DATA_STRUCTURE page 5.2-48 


Call UPM_MAPPER (page 5.2-46) to record a remotely 
detected error of the type SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC 
as indicated by the input parameter. 
Call RECEIVE AND WAIT _PROC( RECEIVE_AND_WAIT)(page 5.1-19) to issue a 
RECEIVE_AND_WAIT verb with the MC_RECEIVE_AND_WAIT verb parameters. 
Select based on the RETURN_CODE from RECEIVE_AND_WAIT: 


When OK 


Interpret the data returned by the RECEIVE _AND_WAIT verb as 
an ERROR_DATA_STRUCTURE. 
If RECEIVE _AND WAIT returns DATA_COMPLETE, the GDS_ID in 
ERROR_DATA_STRUCTURE indicates that the structure contains 
error data (see SNA Formats), and ERROR_DATA_STRUCTURE .ERROR_CODE 
indicates a map execution failure (see SNA Formats) then : 
Optionally log implementation-dependent error data. 
Else (optional check when receiving data; See Note 1 )} 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY (See Note 2) 
Put the RETURN_CODE from the RECEIVE _AND_WAIT verb in the 
MC_RECEIVE_ BUFFER of the current RCB. 
When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED_OUT 
(optional check when receiving data; See Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, DEALLOCATE_ABEND_SVC, or 
DEALLOCATE_ABEND_TIMER (optional check when receiving data; See Note 1) 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
Optionally log implementation-dependent error data. 
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RCVD. SVC_ERROR_PURGING 


5.2-42 


RCVD_SVC_ERROR_PURGING 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 


1. 


This procedure is invoked when PS.MC issues a basic conversation verb in which 
a return code of SVC_ERROR_PURGING is returned. Unlike SVC_ERROR_TRUNC and 
SVC_ERROR_NO_TRUNC, the SVC_ERROR_PURGING return code can be returned ona 
verb issued while the mapped conversation is in either send or receive state. 


The RCB corresponding to the specified conversation. 


A return code reflecting the outcome of the service error processing. 


If the expected Error Data GDS variable is not received, the partner LU has 
committed a protocol violation. The checks for these violations given below 
are optional. If the protocol violation occurred as a result of the partner 
LU allowing the mapped conversation to be prematurely ended without having 
sent the error data, PS.MC simply logs the error. Otherwise, PS.MC ends the 
mapped conversation. In either case, PS .MC returns the code 
RESOURCE_FAILURE_NO_RETRY. 


A return code of RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY can occur 
at any time and does not indicate that the partner LU committed a protocol 
violation. 


Referenced procedures, FSMs» and data structures: 


UPM_MAPPER page 5.2-46 
RECEIVE _AND_WAIT_PROC page 5.1-19 
PROCESS_ERROR_DATA page 5.2-43 
GET_SEND_INDICATOR page 5.2-44 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB page A-6 

ERROR_DATA_STRUCTURE page 5.2-48 


Call UPM_MAPPER (page 5.2-46) to record a remotely 
detected error of the type SVC_ERROR_PURGING as indicated by the 
RETURN_CODE from the last verb issued. 
Call RECEIVE_AND_WAIT_PROC(RECEIVE_AND_WAIT)(page 5.1-19) to issue a 
RECEIVE AND_WAIT verb with the MC_RECEIVE_AND_WAIT verb parameters. 


Select based on the return code in RECEIVE_AND_WAIT: 


When OK 


Interpret the data returned by the RECEIVE_AND_WAIT verb as 
an ERROR_DATA_STRUCTURE. 

If RECEIVE_AND_WAIT returns DATA_COMPLETE and the GDS_ID of 
ERROR_DATA_STRUCTURE indicates that the structure contains 
error data then 

Call PROCESS_ERROR_DATA (page 5.2-43) and 


pass it the ERROR_DATA_STRUCTURE. 


Set RETURN_CODE to the value returned on PROCESS _ERROR_DATA. 
If the RETURN_CODE is not RESOURCE_FAILURE_NO_RETRY then 
Call GET_SEND_INDICATOR (page 5.2-44). 
Else (See Note 1) 

Call PROTOCOL_ERROR_PROC (page 5.2-47) 


to deallocate the current conversation. 


Set RETURN_CODE to RESOURCE_FAILURE_NO_ RETRY. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY (See Note 2) 
Set RETURN_CODE to the value returned on RECEIVE_AND_WAIT. 
When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED _OUT (See Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 


to deallocate the current conversation. 


Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
When DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, 
DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER (See Note 1) 
Optionally log implementation-dependent error data. 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
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PROCESS_ERROR_DATA 


C_ PROCESS _ERROR_DATA 


FUNCTION: This procedure is invoked during the processing that PS.MC performs as a 
result of receiving a return code of SVC_ERROR_PURGING. It is called after 
receiving the Error Data GDS variable that follows the service error notifica- 
tion. The purpose of this procedure is to process the information carried in 
the Error Data GDS variable. 


INPUT: The Error Data GDS variable received from the remote TP 


OUTPUT: If the Error Data GDS variable contains no invalid values, this procedure 


returns a code that reflects the information carried in the error data and 
logs the error information in the system error log. If the error data con- 
tains an invalid value, PS.MC ends the mapped conversation. 


When = the Error Data GDS variable indicates MAP_NOT_FOUND- or 

MAP_EXECUTION_FAILURE, the map name that caused the error is carried in the 

ERROR_PARM field of the Error Data GDS variable. When the Error Data GDS var- 

es, lable indicates INVALID_GDS_ID, the GDS_ID that specifies a function not sup- 

C_ ported by the partner LU or transaction program is carried in the ERROR_PARM 
field. 


Referenced procedures, FSMs, and data structures: 
PROTOCOL_ERROR_PROC page 5.2-47 
ERROR_DATA_STRUCTURE page 5.2-48 


Select based on ERROR_DATA_STRUCTURE .ERROR_CODE: 
When it indicates an invalid GDS_ID (see SNA Formats) 
Select based on the GDS_ID in ERROR_DATA_STRUCTURE .ERROR_PARM: 
When it indicates user control data (see SNA Formats} 
Set RETURN CODE to FMH DATA_NOT_SUPPORTED. 
GO Optionally log implementation-dependent error data. 
| When it indicates map name (see SNA Formats) 
A Set RETURN_CODE to MAPPING _NOT_SUPPORTED. 
Optionally log implementation-dependent error data. 
Otherwise (optional check when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE BUFFER of the current RCB. 
When it indicates map not found (see SNA Formats) 
Set RETURN_CODE to MAP_NOT_FOUND. 
Optionally log implementation-dependent error data. 
When it indicates map execution failure (see SNA Formats) 


ee Set RETURN_CODE to MAP_EXECUTION_FAILURE. 
he : Optionally log implementation-dependent error data. 
a Otherwise (optional check when receiving data) 


Call PROTOCOL_ERROR_PROC (page 5.2-47) 

to deallocate the current conversation. 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE BUFFER of the current RCB. 
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GET_SEND_INDICATOR 


GET_SEND_INDICATOR 


FUNCTION: This procedure is invoked during the processing that PS.MC performs as a 


result of receiving a_ return code of SVC_ERROR_PURGING. 
called after the Error Data GDS variable that follows 


This procedure is 
the service error 


notification has been received and processed. The purpose of this procedure 


is to receive the SEND indication that follows the Error Data GDS variable. 


INPUT : The RCB that corresponds to the specified conversation 


OUTPUT : A return code reflecting the results of the processing 


Referenced procedures, FSMs, and data structures: 
RECEIVE_AND_WAIT_PROC 
PROTOCOL_ERROR_PROC 
RCB 


Call RECEIVE_AND_WAIT_PROC(RECEIVE_AND_WAIT)(page 5.1-19) to issue a 
RECEIVE _AND_WAIT verb with the MC_RECEIVE_AND_WAIT verb parameters. 


Select based on the return code in RECEIVE_AND_WAIT: 
When OK (optional check when receiving data) 
If RECEIVE AND_WAIT returns WHAT_RECEIVED other than SEND then 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Set RETURN CODE to RESOURCE_FAILURE_NO_RETRY. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY 
Set RETURN_CODE to the value returned on RECEIVE_AND_WAIT. 
When DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, 
DEALLOCATE_ABEND_SVC, or DEALLOCATE_ABEND_TIMER 
(optional check when receiving data) 
Set RETURN _CODE to RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. 
When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED_OUT 
(optional check when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
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page 5.1-19 
page 5.2-47 
page A-6 


SEND_SVC_ERROR_PURGING 


(— SEND_SVC_ERROR_PURGING 


FUNCTION: This procedure performs service error purging processing. It is invoked when 
PS.MC receives a GDS variable specifying a function not supported by either 
the LU or the transaction program associated with the mapped conversation over 
which the GDS variable flowed, or when PS.MC receives a GDS variable contain- 
ing an unrecognized GDS ID, or when data mapping is being performed and the 
mapper procedure has encountered an error in mapping the received data. 


The RCB- for the conversation on which the’ service error occurred; an error 
code specifying the type of error encountered; and an error parameter that 
provides more information about the error 


OUTPUT : If any of the verbs issued by this procedure do not complete successfully, the 
procedure inserts into the RCB.MC_RECEIVE_ BUFFER an appropriate return code. 


NOTE : If mapping is supported and the mapper does not already Know about the error, 
the mapper is notified of the type of error encountered. The mapper is not 
invoked when the error encountered is a MAP_NOT_FOUND or MAP_EXECUTION_FAILURE 

a condition--the mapper is already aware of the error. (The mapper discovered 

C J the error.) If the error encountered indicates MAPPING_NOT_SUPPORTED, no 

- mapper exists. 


Referenced procedures, FSMs, and data structures: | 
UPM_MAPPER page 


5.2-46 
PREPARE_TO_RECEIVE_PROC page 5.1-18 
SEND_DATA_PROC page 5.1-24 
SEND _ERROR_PROC page 5.1-25 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB page A-6 
ERROR_DATA_STRUCTURE page 5.2-48 
woes If the input error code indicates an invalid GDS_ID (see SNA Formats) 
a and the GDS_ID in the input error parameter does not indicate a map 
we name (see SNA Formats) then 


Call UPM_MAPPER (page 5.2-46) to record a remotely detected error 
of the type SVC_ERROR_PURGING, as indicated by the RETURN_CODE from 
the last verb issued. 

Call SEND_ERROR_PROC(SEND_ERROR)}(page 5.1-25) to issue a SEND_ERROR . 
verb with the’ MC_SEND_ERROR verb parameters, specifying error type SVC 
and implementation-dependent error log data. 

Select based on the return code in SEND_ERROR: 

When OK 
Create an ERROR_DATA_STRUCTURE (a single logical record) using the 
data in the parameters ERROR_CODE and ERROR_PARM. 
pO NS Call SEND _DATA_PROC (page 5.1-24) to issue a SEND_DATA 
q verb to send the ERROR_DATA_STRUCTURE to the remote TP. 
a Select based on the return code from SEND_DATA: 

When OK 
Call PREPARE_TO_RECEIVE_ PROC (page 5.1-18) to issue 
a PREPARE_TO_RECEIVE verb for the current conversation with the type 
parameter set to FLUSH and locks set to SHORT. 

When RESOURCE _FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY 
Put the RETURN CODE from SEND _DATA. in the MC_RECEIVE_ BUFFER 
of the current RCB. 

When PROG_ERROR_PURGING, SVC_ERROR_PURGING, or BACKED_OUT 
(this check is optional when receiving data) 
Call PROTOCOL _ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RETURN_CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_ BUFFER of the current RCB. 

When DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER; 

or DEALLOCATE_ABEND_PROG (optional check when receiving data) 
Optionally log implementation-dependent error data. 
Put the RETURN CODE RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE BUFFER of the current RCB. 


os When DEALLOCATE_NORMAL, RESOURCE_FAILURE_RETRY, or RESOURCE_FAILURE_NO_RETRY 
C ; Put the RETURN_CODE from SEND_DATA in the MC_RECEIVE BUFFER 
7 
aid of the current RCB. 
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UPM_MAPPER 


5.2-46 


UPM_MAPPER 


FUNCTION: 


INPUT : 


OUTPUT : 


This procedure, referred to elsewhere in this chapter as "the mapper," per- 
forms mapping of data in an implementation-defined way. The MAPPER_SAVE_AREA 
in the RCB for the current conversation contains information used in data map- 
Ping, such as the currently effective map names (see "Map Names" on page 
5.2-8). Refer to "Data Mapping and the Mapper" on page 5.2-8 for a detailed 
description of the processing that occurs when data is mapped. 


1. Reason why the mapper was invoked: 


e Data is to be sent to, or was received from, the partner LU. The map name 
supplied by the sending TP determines the Kind of mapping to occur. 


e An error occurred and was detected either remotely or locally. 


e )6=—hOA positive reply to CONFIRM or to SYNCPT was received. This positive con- 
firmation informs the mapper that any map names sent to the partner have 
been received and processed by it, and were not purged during error proc- 
essing. | ; 


2. The polarity indicates whether send mapping or receive mapping is’ to be 
performed. This parameter is used when the mapper invocation is for data map- 


Ping. 


3. The RH Format indicator indicates whether the passed data includes FM 
headers. The mapper requires this information in the event that the same map 
name could cause a different mapping to take place depending upon whether the 
data being mapped includes FM headers. This parameter is used when the mapper 
invocation is for data mapping. 


4. Input map name contains the locally Known map name supplied by the TP on 
an MC_SEND_DATA, if send mapping is to be performed; or the map name that 
flows in a Map Name GDS variable between LUs, if receive mapping is to be per- 
formed: This parameter is used only if the mapper invocation is for data map- 


ping. 


5. Input data contains the data supplied by the TP on the MC_SEND_DATA verb 
for SEND mapping,» or data that flows in a Data GDS variable for RECEIVE map- 
Ping. This parameter is used only in data mapping. 


6. Error code informs the mapper of the type of error encountered (for exam- 
ple, SVC_ERROR_PURGING or PROG_ERROR_NO_TRUNC). This is needed when the 
mapper invocation is for an error occurrence. 


1. Output map name contains the "mapped" (global) map name that is sent to 
the partner LU if send mapping is performed, or the locally Known map name 
that is passed to the TP if receive mapping was performed. This output is 
returned when the mapper invocation was for data mapping» and always after 
receive mapping. 


2. Output data contains the data that is sent to the partner LU for send map- 
ping, or the data that is passed to the TP for receive mapping. This data is 
returned if the the mapper was called for data mapping. 


3. Mapper return code indicates whether the mapper successfully performed the 
mapping or encountered problems, and is _ returned after data mapping inv- 
ocations. 
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PROTOCOL_ERROR_PROC 


PROTOCOL_ERROR_PROC 


This procedure handles protocol error processing. It is invoked when PS.MC 
detects an architectural protocol error committed at the partner LU. 


The RCB corresponding to the mapped conversation over which the protocol vio- 
lation occurred. 


Error log data is entered into the system log by PS.CONV (Chapter 5.1) during 
its processing of the DEALLOCATE issued by this procedure. 


Referenced procedures, FSMs, and data structures: 
DEALLOCATE_PROC page 5.1-15 


C RCB page A-6 
ae Call DEALLOCATE_PROC( DEALLOCATE }(page 5.1-15) to issue a DEALLOCATE 
verb with the MC_DEALLOCATE verb parameters, specifying a deallocation type 
of ABEND_SVC and indicating that the resource ID is to be discarded. 
Optionally, implementation-dependent error data may be recorded in the 
system error log. 
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LOCAL DATA STRUCTURES 


5.2-48 


ERROR_DATA_STRUCTURE 


ERROR_DATA_STRUCTURE: an instance of a GDS variable 
LL_LENGTH: the high-order bit is set to 0 indicating a single-segment record 
GDS _ID (see format of an Error Data GDS variable in SNA Formats) 
DATA . 
ERROR_CODE (see SNA Formats) 
ERROR_PARM (see SNA Formats ) 


| SEND_BUFFER 


SEND_BUFFER: a buffer containing the mapped data to be sent. 
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Recovery from errors and failures is a cen- 
tral consideration in the design of trans- 
action programs. LU 6.2 provides optional 
services to aid transaction programs § in 
recovery from errors. A synchronization 


ERRORS, FAILURES, AND RECOVERY 


Errors and failures can be classified as: 


e Application  errors--these errors’ may 
occur frequently; recovery is part of the 
application design. In data entry, for 
instance, field validation and requests 
for repeated input are normal portions of 
the application logic. 


e Recoverable system errors--these errors 
occur frequently; recovery is part of the 
system logic. Bracket race errors are an 
example (see "Chapter 6.1. Data Flow Con- 
trol");  link-level retransmission is 
another. 


° Transaction program failures--transaction 
programs sometimes end abnormally. Ina 
well-tested system, this will not occur 
frequently. Application-level recovery 
varies by application. See “Chapter 5.1. 
Presentation Services--Conversation 
Verbs" for details of abnormal termi- 
nation processing. 


e Conversation failures--conversations will 
sometimes fail as a result of failure of 
the underlying sessions caused by the 
physical components over which the ses- 
sions are carried. The reactivation of 
failed sessions is handled by system log- 
ic; see “Chapter 4. LU Session Manager" 
for details. Application-level recovery 
from conversation failure is discussed in 
more detail in SNA Transaction Program- 


mer's Reference Manual for LU Type 6.2. 


service is selected by the SYNC_LEVEL parame- 
ter in the ALLOCATE verb. This chapter is 
primarily concerned with the sync point syn- 
chronization services. } 


° LU failures--LUs will sometimes fail by 
themselves or as a result of the failure 
of underlying hardware or software. Much 
of the recovery from LU failures, as seen 
by other LUs, is handled by the recovery 
of sessions that have’ failed. Other 
aspects of this recovery are the concern 
of sync point services. 


e Local resource failures--local resources 
(e.g.» files) will sometimes fail. If 
the local resource that fails is not pro- 
tected by the sync point service, recov- 
ery is an application-level 
responsibility. 


Applications are often designed as a sequence 
of logical units of work, each unit consist- 
ing of some changes to the resources under 
the control of the transaction program. Each 
logical unit of work (LUW) is recoverable by 
itself. The simplest case occurs when there 
is one LUW for a transaction program; recov- 
ery can often then consist of running the 
transaction again from the beginning.  LUWs 
are delimited by the start-up of a trans- 
action program and by execution of = each 
SYNCPT verb. The SYNC_LEVEL(SYNCPT) service 
simplifies the design of transaction programs 
that use protected resources, since changes 
to those resources will be seen by the appli- 
cation transaction program as having occurred 
only after one LUW completes and before the 
next LUN begins. 


Figure 5.3-1 on page 5.3-2 illustrates the 
relationships among failures and recovery. 


1 Full support of sync point services in actual implementations includes provisions for syn- 
chronizing local resources as well as distributed resources accessed through conversations. 
For completeness, this section sketches fully general sync point services. Details of sync 
point services for local resources are not specified by SNA, but are implementation defined. 

2 The sync point service is not always able to provide a consistent state for the protected 
resources. When this occurs, a heuristic decision is made. This sometimes damages the LUW 
by making the states of its protected resources inconsistent. More details about this are 
provided in "RESOURCE_FAILURE_*, Recovery, and Heuristic Decisions" on page 5.3-15. 
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Figure 5.3-1. 
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SYNC POINT CONCEPTS 
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The 
this 


SNA 


following are some terms that are used in 
chapter: | 


SYNCPT—A verb used by a transaction pro- 
gram (TP) to invoke sync point services. 
Sync point services coordinate the 
updates of distributed resources. Coor- 
dination is performed by the sending and 
receiving of presentation services (PS) 
headers by the sync point services compo- 
nent. The protocol allows recovery if 
messages are lost because of transaction 
program, conversation, or LU failures. 


INITIATOR—The role of the local sync 
point services component when the TP 
issues the SYNCPT verb that begins the 
coordinated update of distributed 
resources. 


AGENT—The role of the sync point serv-. 
ices component that receives sync point 


requests from an initiator. 


LU 6.2 Reference: Peer Protocols 


CASCADED AGENT—An agent of an initiator 
that is itself an agent of another initi- 
ator; in other words, an agent may allo- 
cate other protected conversations. In 
this role an agent is responsible for 
propagating sync point requests to its 
cascaded agents. 


RESYNC—-Recovery processing that is per- 


formed by sync point services after a 
failure of a session, transaction pro- 
gram, oor LU. The resync exchange 


includes exchanging log names and compar- 
ing LUW states. 


PRESENTATION SERVICES (PS) HEADER—The 
requests and replies that sync point 
services components exchange to perform 
SYNCPT verb processing. 


(3 


\ 
~ 


7» PROCESSING BY PS.SPS 


TP 


The component of LU presentation services 
that provides the sync point service is 
called PS.SPS, also called the sync point 
manager. When all the resources used by a TP 
are at one LU, only one copy of PS.SPS is 
executed. Usually the situation is more com- 
plicated since every conversation allocated 
with the SYNC_LEVEL(SYNCPT) option connects 
two separate TPs, which cooperate to perform 
one or more distributed units of work. In 
the distributed cases, one TP is the first to 
issue the SYNCPT verb, and its local sync 
point manager becomes the sync point initi- 
ator for the current sync point, with respect 
to the sync point managers on the other ends 
of any conversation. These other sync point 
managers become agents with respect to the 
initiator, but may in turn become initiators 
with respect to additional, cascaded» sync 
point managers. 


The sync point managers maintain consistency 
of the changes to protected resources by the 
propagation throughout the network of these 
sync point commands: 


e Prepare--Solicits Request Commit. This 
command tells the agent to place its pro- 
tected resources in a state that allows 
them to be fully committed to the changes 
that have been accumulated during this 


TP 3 

TP 2 
TP 4 

1 TP 5 
TP 6 TP 7 


presentation 


LUN, but that also allows these changes 
to be reversed, or backed out. The 
choice to commit or back out is made by 
the initiator after interaction with all 
agents. 


® Request Commit--Solicits Committed. This 
command says that the issuer has suc- 
ceeded in preparing all of its protected 
resources. 


e Committed--Informs the soliciting sync 
point manager that all resources attached 
through this conversation are committed. 


e Forget--Informs the sync point manager 
that sent Committed that its log record 
for this LUW can be erased.* Forget also 
tells the initiating sync point manager 
that the sync point is complete and that 
control can be returned to the TP. 


° Backed Out--Informs the receiving sync 
point manager that the sending sync point 
manager has backed out the LUW. 


The SNA encoding for transmission of these 
commands are described in SNA Formats under 
services (PS} headers for the 
first four, and FMH-7 sense data for Backed 
Out. 


Figure 5.3-2. 


A Typical Sync Point Tree 


The sync point managers Keep records about LUWs on logs, held on nonvolatile storage by the 
log manager, so that LUWs can be kept consistent across failures of LUs. The logical unit 
of work ID (LUWID) is comprised of three components: the fully qualified LU network name; 
the instance number, which is unique at the LU that creates it; and the sequence number, 
which is incremented by 1 following a successful sync point. In addition, a conversation 
correlator is used to further qualify LUWIDs. The LUWID is created by RM for a conversation 
whenever a conversation is allocated by a TP that does not already have an LUWID associated 
with it. <A TP already has an LUWID associated with it, if it was the subject of an Attach 
by a TP that already has an LUWID. The LUWID and conversation correlator are carried in the 
FMH-5 (see SNA Formats). 
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LUN STATES 


A distributed transaction program is a tree, 
with individual TPs as nodes on the tree, and 
conversations as branches. Distributed TPs 
support distributed LUWs, consisting of local 
LUNs at the individual TPs. The distributed 
LUW has a state made up of all the local LUW 
states. For the distributed transaction pro- 
gram shown in Figure 5.3-2 on page 5.3-3, the 
distributed LUW state is a vector with seven 
components: 


LUN = [LUW1,LUWN2, ... LUW7] 
where LUW1 is the local LUW state for TPi. 


The first TP to issue SYNCPT becomes the root 
of the tree for the global LUW that is ended 


PS.SPS PS.SPS 
Initiator | Agent 


SYNCPT 
SS Prepare 
> TAKE_SYNCPT * 
> 
SYNCPT 
< 
Request Commit 
< 
Committed 
> 
Forget 
< 
OK 
< 


by that verb. In the figure, the root, or | 


initiator, is TP l. 


The sync point managers at each node of the 
tree cooperate to place all the LUW compo- 
nents into the same consistent state. They 
do this with four waves of sync point com- 
mands. | 


The Prepare wave starts at the root and 
spreads down the tree. The Request Commit 
wave starts at the leaves (nodes without sub- 
ordinate nodes) and spreads up the tree to 
the root. The Committed wave returns down 
the tree, and the Forget wave flows up the 
tree to the root. Figure 5.3-3 shows these 
waves as they occur between the root and one 
of the nodes adjacent to the root. 


NOTE: TAKE_SYNCPT is returned in the WHAT_RECEIVED field of verbs that can receive data. 


Figure 5.3-3. Basic Sync Point Flows 
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Figure 5.3-4. Optimized Flow: No Resource Changed 
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Figure 5.3-5. Optimized Flow: Last Resource 
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FLOW OPTIMIZATION 


Since message flows are costly, the sync 
point managers attempt to reduce the number 
of flows. Figure 5.3-4¢ on page 5.3-4¢@ illus- 
trates one such case: when a sync point man- 
ager agent determines that the state of the 
local LUW is reset, that is» no protected 
resources have been changed, it answers For- 


see get to Prepare. Intermediate agents can 
a * reply Forget only if all the local LUWs in 
or. their entire subtree are reset. 


Figure 5.3-5 shows the other flow reduction 
that can be used. The initiator can pick one 
adjacent agent to receive Request Commit 
rather than Prepare. The Request Commit can 
be sent only after all the prepared agents 
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have sent Request Commit up their subtree to 
the initiator, making the selected agent the 
last agent. This last agent is then free to 
select one of its cascaded agents also to be 
last, and so on. 


Message flows are further reduced because the 
PS header that starts the sync point exchange 
indicates that one of three things should 
occur after the sync point message exchange 
is complete: the initiator is to be in send 
state, the initiator is to be in receive 
state, or the conversation is to be deallo- 
cated. This is shown in Figure 5.3-32 on 
page 5.3-38 to Figure 5.3-36 on page 5.3-40. 
The first PS header sent has a modifier field 
that indicates the setting of the CD and CEB 
indicators of the RH that completes the sync 
point exchange. 


Manager 


Figure 5.3-6. Syne Point Services for Local (Nonconversational) Resources, Such as Files 
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SYNC POINT AND OTHER LU COMPONENTS the sync point manager, which coordinates( | 
the action of all sync point managers a 
involved in the distributed LUW. 


The relationships among the transaction pro- 


gram, its resources, and the sync point man- 4. The sync point manager interacts with the 
ager are illustrated in Figure 5.3-6 through | protection manager for each protected 
Figure 5.3-8. resource, exchanging PS headers indicat- 
ing Prepare, Request Commit, Committed, 
The following notes correspond to the numbers and Forget to coordinate commitment, or 
in Figure 5.3-6 on page 5.3-5. an FMH-7 indicating Backed Out to coordi- 
nate backout of changes, either = as 
1. The transaction program issues a resource requested by the TP, or as required by a 
verb, which is passed, by the PS router, resource failure. 
to the proper procedure to handle the 
local resource. See "Chapter 5.1. Pres- 5. When all resources are prepared, the LUW 
entation Services--Conversation Verbs" is committed when the sync point manager 
for details. writes Committed on the log» and forces 
the log.® The single force of the log is 
2. The local resource is protected, and so sufficient to commit the entire LUNW 
it has a protection manager, which exam- because all local resources used by a 
ines the resource verb. If the resource single TP share a single log, which is , 
is changed by the verb (e.g.» it is a also the log used by the TP's sync point | 
Write of some Kind), the protection man- manager. 7 
ager writes a log record containing the 
before—change data.“ Recovery that uses the log records is 
discussed later in "Resynchronization 


Logic" on page 5.3-18. 
3. Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 


4 Logging before-change data is the technique suggested in the formal description. Other 
equivalent techniques are possible and permissible. 

5 Some writes to the log can be made to volatile log buffers. If these are lost because of - 
failure of the LU, no damage results. Other writes (called forced writes) to the log mus\ 
be made to the nonvolatile log itself before the sync point protocol can proceed, if the LUN--~ 
is to be Kept synchronized even across LU failures. This use of the nonvolatile log is 
called forcing the log. 
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The following notes correspond to the numbers 
in Figure 5.3-7. 


The transaction program uses a conversa- 
tion. The conversation resource (CR) 
protection manager is not sensitive to 
any of the conversation verbs. 


The CR protection manager does not write 
any log records. RM does write log 
records as part of ALLOCATE processing in 
order to be able to re-create the 
resource control blocks (RCBs) and their 
relationship to transaction control 
blocks (TCBs) following an LU failure. 
See RCB on page A-6 for details of the 
RCB and TCB. 


Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 
the syne point manager to do the coordi- 
nation. 


The syne point manager interacts with the 
protection manager for each protected 
conversation, exchanging Prepare, Request 
Commit, Committed, and Forget PS headers 
to coordinate commitment, or Backed Out 
to coordinate backout of changes, either 
as requested by the TP, or as required by 
a resource failure. 


Log 
Manager 


Sync Point Services for Conversation Resources 


Protected conversations are treated some- 
what differently from protected local 
resources; this difference is driven by a 
Backed Out FMH-7 can be received from 
nonlocal resources. Compare States GDS 
local/nonlocal® indicator in the RCB. A 
variables (also referred to as Compare 
States command or reply) can be exchanged 
with them to resynchronize following con- 
versation failures. 


The local protection manager for the con- 
versation communicates with its remote 
partner by exchanging PS headers and the 
Backed Out FMH-7 sense data. The 
half-session has no Knowledge that a pro- 
tected conversation is assigned to it. 


The sync point manager has to do addi- 
tional writes to the log whenever nonlo- 
cal resources are pointed to by a TCB. 
Also, additional forces of the log are 
required. Finally, the sync point manag- 
er attempts  resynchronization by = an 
exchange of Compare States GDS variables 
with its partner sync point manager after 
resource failures. 


Local resources are those that share the sync point manager's log. 
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Figure 5.3-8. Syne Point Services for Function Shipping 
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The following notes correspond to the numbers 
in Figure 5.3-8. 


de 


SNA LU 6.2 Reference: 


The transaction program allocates a 
resource that is located remotely. The 


local resource manager uses a conversa-: 


tion to communicate to the remote 
resource. 
Neither the local-resource protection 


manager nor the CR protection manager 
writes log records. The only logging is 
done by RM in order to be able to 
re-create the resource RCBs and their 
relationship to  TCBs. The ALLOCATE 
issued by the local resource manager is 
understood to be for a function shipping 
situation, so the conversation's RCB is 
chained under the local resource's RCB 
rather than being chained directly to the 
TCB. At the same time, the local 
resource's RCB is marked nonlocal. 


Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 


Peer Protocols 


(5) 
> Log 
Manager 


Cae 
an 
C 


the sync point manager to do the words 


nation. 


The sync point manager interacts with the 
protection manager for each protected 
resource, exchanging Prepare, Request 
Commit, Committed, and Forget PS headers 
to coordinate commitment, and Backed Out 
to coordinate backout of changes, either 
as requested by the TP, or as required by 
a resource failure. 


The nonlocal resources are treated the 


same as protected conversations: Backed 
Out can be received; Compare States GDS 
variables can be exchanged. 


The protection manager for the _ local 
resource, after dealing with local states 
(e.g.» on a Prepare it may need to flush 
a local buffer), passes the PS headers 


omit 


that it receives from the sync point man- 


ager to the CR protection manager. 


. rh 
Ne 


for details. 


5. The syne point manager has to do addi- 
tional writes to the log whenever nonlo- 
cal resources are pointed to by a TCB. 
Also, additional forces of the log are 
required to handle the extra error states 
introduced by the existence of remote 
logs. Finally, the sync point manager 
attempts resynchronization via exchange 
of Compare States GDS variables with 
partner sync point =managers = after 
resource failures. 


SYNC POINT LOGIC 


A transaction program can issue a SYNCPT verb 
as an initiator, or in_ reply to a 
WHAT RECEIVED value of TAKE_SYNCPT >, 
TAKE_SYNCPT_SEND, or TAKE_SYNCPT_DEALLOCATE 
on RECEIVE. After giving the TAKE_SYNCPT 
indication, the conversation resource rejects 
most verbs until SYNCPT,  BACKOUT, or 
SEND ERROR is issued. See SNA Transaction 


PS.SPS processes the SYNCPT verb in the 
phases described below. 


CLASSIFICATION PHASE 


Since SYNCPT can be issued under many circum- 
stances, PS.SPS begins by = scanning the 
resources allocated to the transaction pro- 
gram in order to determine their states. 
Further PS.SPS processing varies according to 
the states of the local resources and TP: 


1. PREPARE RECEIVED state--Prepare § was 
received from an initiating sync point 
manager. The local TP did not initiate 
sync pointing. PS.SPS prepares its local 
and down-tree protected resources and 
replies up-tree with Request Commit if 
preparation succeeds. If it fails, it 
replies Backed Out. 


2. REQUEST COMMIT RECEIVED state--Request 
Commit was received from an initiating 
sync point manager. The local TP did not 
initiate sync pointing. Since the initi- 
ating PS.SPS has used an optimized flow, 
which it can do only for the last 
resource that it is attempting to coordi- 
nate, the local PS.SPS coordinates the 
commitment of its local and down-tree 
resources and replies Committed if com- 
mitment succeeds. If it fails, it 
replies Backed Out. 


3. SEND state--All protected conversations 
are verified to be in SEND state. Before 
issuing the SYNCPT verb, the transaction 
program puts all its protected resources 
into SEND state. If required, this can 
be done by issuing REQUEST_TO_SEND and 
waiting for the right to send. 


4. Unprotected resource--Resource was allo- 
cated with SYNC_LEVEL(NONE | CONFIRM). 


The resource is not affected by the 
SYNCPT verb. 


At the end of the scan, PS.SPS Knows if a 
resource (1.e., the one in PREPARE RECEIVED 
state) must be sent Request Commit during its 
local coordination. Request Commit must be 
sent last, after all other resources have 
been prepared. If no last resource is iden- 
tified, a UPM is used to select one. The UPM 
can consider things like minimizing session 
flows (which leads to making a remote conver- 
sation last whenever possible). It can also 
choose to prepare all resources, which allows 
all coordination to proceed in parallel, 
since Prepares can be sent simultaneously to 
several resources. 


If any protected resources are in Receive 
state or more than one last resource is iden- 
tified, the sync point manager recognizes a 
state error and abnormally terminates the TP. 
Since any TP may be sync point initiator, the 
design of the distributed TPs must be such 
that only one TP at a time is the initiator. 
For example, TPa is in conversation with TPb 
and TPb has a cascaded conversation with TPc. 
If TPa and TPc both initiate sync point with 
TPb at the same time, it is an error in the 
design of the transaction program. The sync 
point service at TPb recognizes this error 
and returns BACKED_OUT to TPb. TPb then 
issues the BACKOUT verb. Otherwise, PS.SPS 
advances to the Prepare phase. 


PREPARE PHASE 


PS.SPS now issues Prepare to all not-last 


resources. When Request Commit has _ been 
received from all of them, the next phase is 
entered. Other replies to Prepare are dis- 


cussed in "Errors during Sync Point" on page 
5.3-15. If no not-last resources exist, this 
phase is sKipped and PS.SPS proceeds directly 
to the Request Commit phase. 


REQUEST COMMIT PHASE 


After receiving Request Commit from all 
not-last resources, PS.SPS issues Request 
Commit to the last resource, and waits for a 
reply, thus entering the Committed phase. 


COMMITTED PHASE 


PS.SPS completes sync point processing after 
receiving Committed from the last resource by 
sending Committed to all not-last resources, 
thus entering the Forget phase. 


FORGET PHASE 


In the Forget phase, PS.SPS waits for Forgets 
from all the not-last resources. When all 
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fo 


5.3-10 


Forgets have been received, PS.SPS gives the 
SYNCPT verb that was issued by the local TP a 
return code of OK. 
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The following figures and comments illustrate 
the preceding discussion. 
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NOTE: The * indicates sending to» or receiving from, multiple agents. 


Figure 5.3-9. Illustrative Sync Point Flow: General Case 


The following notes correspond to the numbers 
in Figure 5.3-9. 


state. Any change to a. local protected 
resource or receipt by PS of any message 


— 1. The distributed LUN begins in RESET 
| 
C . . e o e oe 
unit (including the initial Attach) over 


a protected conversation drives a local 
LUW from RESET to PGM PENDING. 


The initiating TP issues SYNCPT. PS.SPS 
logs all affected conversations except 
the last as [INITIATOR, SPM PENDING] 
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while the last one is not logged yet.” 8. An implied Forget is sent to the last 
The log is forced once. PS.SPS sends agent with the aid of RM and the session~ ~ 
Prepare to all but the last agent (where process. The implied Forget is the nex‘ | 
the * at the end of Prepare means all the normal-flow RU of any Kind that flows\—- 
agents, except possibly the last). from the initiator to the last agent. 

For instance, if the agent sent Committed 

3. Each agent PS.SPS returns to its trans- as CEB, then the next RU might be a (BB, 
action program, a WHAT_RECEIVED value of Attach); or it might be a (BB, LUSTAT); 
TAKE_SYNCPT. All TPs agree by issuing or BIS; or a data reply to a BB that came 
SYNCPT. from the agent's half-session. Since the 

Committed can get lost, the agent retains 

G4. The agent PS.SPS logs [AGENT, SPM PEND- the state of the LUW across session out- 
ING] for the conversation over which the age. Since the implied Forget can get 
Prepare is received. It logs [INITI- lost, and since the initiator may have 
ATOR—CASCADE, SPM PENDING] for all the erased its log, the agent carries a 
cascaded conversations, if any exist resynce responsibility for itself. Only 
(there might only be local resources). in this way can it erase its log. "Re- 
The log is forced once if amd only if any synchronization Logic" on page 5.3-18 
cascaded conversations exist. describes resync in more detail. 

5. All cascaded agents agree to commit. 9. PS.SPS logs [Initiator-Cascade, Commit- 
PS.SPS places [AGENT, IN DOUBT] on the ted] for all cascade agents and forces 
log and forces the log. the log. It then sends Committed to th 

cascaded agents. L ; 

6. All agents agree to commit. [INITIATOR; 

IN DOUBT] is placed on the log if and 10. All cascaded agents’ return’ Forget. 

only if the last resource is being opti- PS.SPS resets the LUW by erasing the log; 

mized with the last-resource sequence. then PS.SPS sends Forget to the initiator, 

If IN DOUBT is placed on the log, the log and returns control to the agent TP. 

is forced and then Request Commit is sent 

to the last agent. 11. All agents return Forget. PS.SPS erases 
the log and returns control to the initi- 

7. The last agent replies Committed (if the ating TP. The log does not have to be 
optimized flow is being used for the last forced before PS.SPS sends Forget, since 
agent). [CINITIATOR, COMMITTED] is logged any Forgets lost during a failure can be 
and the log is forced. Committed is sent reconstructed by resynchronizing wit!” > 
to all agents (except the optimized cascaded agents. | 
last). S 


( 


7 ~The log records are [state of local PS.SPS relative to remote PS.SPS, state of local LUN]. 
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Illustrative Sync Point Flow: 


The following notes correspond to the numbers 
in Figure 5.3-10. 


1. 


The distributed LUN begins in _ RESET 
state. Any change to a local protected 
resource or receipt by PS of any message 
unit (including the initial Attach) over 
a protected conversation drives a local 
LUW from RESET to PGM PENDING. 


The initiating TP issues SYNCPT. PS.SPS 
logs the last conversation as [INITIATOR, 
IN DOUBT]. It forces the log and sends 
Request Commit. 


The agent PS.SPS presents TAKE_SYNCPT to 
the agent transaction program. The TP 
agrees by issuing SYNCPT. 


The agent PS.SPS logs [AGENT, SPM PEND- 
ING] for the conversation over which the 
Request Commit is received. It logs 
[INITIATOR-CASCADE, SPM PENDING] for all 
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Last-Resource Optimization 


the cascaded conversations, if any exist 
(there might be only local resources). 
It forces the log if and only if any cas- 
caded conversations exist. 


All cascaded agents agree to commit. The 
agent PS.SPS logs [INITIATOR-—CASCADE ,» 
COMMITTED] and forces the log again (in 
the example, the agent is not using the 
last-resource optimization on cascaded 
resources). Then it sends Committed to 
all cascaded agents. 


The agent PS.SPS waits for all cascaded 
agents to return Forget. This is done so 
that, in case of failures and resynchro- 
nization, it can return to the initiator 
an accurate report of any damage that may 
occur from heuristic decisions (discussed 
in "DEALLOCATE_ABEND_*" on page 5.3-15). 


All Forgets are returned. The subtree 
for which this PS.SPS is responsible is 


5.3-13 


SYNCPT 


NOTE: 


Figure 


5.3-14¢ 


> 


> 


COMMITTED. The agent PS.SPS returns Com- 
mitted to the initiator, even if no 
down-tree resources were changed, and 
then returns control to its TP. 


The initiator sees the Committed. If 
there are no other participants, the ini- 
tiator erases the log for the LUW and 
returns OK to the initiating transaction 


program. If there are other agents, [IN- 
ITIATOR,COMMITTED] is placed on the log 
eee cor 
Initiator Agent 
RESET RESET 
V Vv 
(1) < 


I 
PGM PENDING PGM PENDING 


| 
v 


(2) Prepare* 
Aa) TAKE_SYNCPT 
> 
SYNCPT 
V< 


A 
SPM PENDING 


SPM PENDING 


Forget V  RETURN_CODE 


Vo <——————_(4)  ———> 


(5) 


while the Forgets from the not-last 
agents are collected. See Figure 5.3-9 
on page 5.3-11 for this type of sequence. 


Implied Forget is sent to the last agent 
with the aid of the session process. 
That is» any conversation data that flows 
on the half-session is treated as an 
implied Forget. This includes a BB that 
begins a new conversation when Committed 
was sent with CEB. 


Cascaded 
Agent 


The * indicates sending to, or receiving from, multiple agents. 


5.3-ll. 


Illustrative Sync Point Flow: 


The following notes correspond to the numbers 


in 


Figure 5.3-11. The situation that the 


figure illustrates arises when a sync point 


is requested, 
been altered during the LUW. 


but no remote resources have 
In this case, 


the Request Commit and Committed flows are 
not necessary and are omitted. 


l. 
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The distributed LUW begins in RESET 
state. Any change to a local protected 
resource or receipt by PS of any message 
unit (including the initial Attach) over 
a protected conversation drives a local 
LUW from RESET to PGM PENDING. | 


The initiating TP issues SYNCPT. PS.SPS 
logs all affected conversations but the 
last as [INITIATOR, SPM PENDING], not 
logging the last one yet. It forces the 
log once, then sends Prepare to all but 
the last agent (represented by the * fol- 
lowing Prepare). 


Peer Protocols 


No Resources Changed 


— 
The agent PS.SPS presents TAKE_SYNCPT to f- 


the agent TP, which agrees to commit. 
The rest of this flow illustrates the 
processing performed by a single agent 
where no resources have been changed. 
The generalization to cascaded LUWs is 
straightforward. 


The agent PS.SPS sees (by receiving For- 
gets from the local resources) that no 
resources have been changed. It resets 
the LUW by erasing the log, sends Forget 
to the initiator, and returns control to 
the agent TP. 


The agent returns Forget. The Request 
Commit and Committed flows were not 
needed; the initiator PS.SPS still proc- 
esses the flows from other conversations 
that may or may not require the addi- 
tional flows. 


\ 


( 
e 


/ 
a 


FORCING THE LOG 


PS.SPS needs to force the log only once when 
all resources are local, while it uses at 
least two forces of the log as the initiator 
(SPM PENDING and COMMITTED states) and may 
use an additional force (IN DOUBT state) if 
the last resource is flow optimized. 


PS.SPS uses at least one log force as the 
agent (IN DOUBT state), but if any cascaded 


ERRORS DURING SYNC POINT 


& 


The preceding discussion assumed that sync 
point processing completed normally, without 
incident. This section shows how consistency 
can be maintained even when errors occur. 


The errors addressed are those caused by many 
transaction programs operating independently 
of each other, communicating only when 
required. With this independence, unexpected 
return codes can occur after any verb. As 
the issuer of internal verbs to the conversa- 
tion resource protection manager (PS.CRPM) in 
order to exchange sync point commands with 
partner sync point managers, PS.SPS has logic 
to deal with these return codes: 


PROG_ERROR_*, including SVC_ERROR_* 
BACKED_OUT 

DEALLOCATE_ABEND_* 
RESOURCE_FAILURE_* 


Because recovery from conversation failure 
can require that a session be reactivated, 
PS.SPS gives special consideration to the 
case where this cannot be accomplished in a 
timely manner. 


PROG_ERROR_* 


PS.SPS treats PROG_ERROR_*® as BACKED_OUT. It 
is the using transaction program's responsi- 
bility to avoid this by correct transaction 
design. 


BACKED_OUT 


BACKED_OUT is the return code given when the 
remote transaction program issues a BACKOUT 
verb. Unlike the case of PROG_ERROR_*, where 
the TP that issued SEND_ERROR gives the TP 
that receives the PROG_ERROR_¥ an option, on 
BACKOUT the issuing TP expects the entire 
distributed LUW to be backed out. The TP 
that receives BACKED_OUT therefore propagates 
the backout to all other resources by also 
issuing the BACKOUT verb. 


conversations exist for this LUW, the agent 
PS.SPS has to appear to the cascaded agents 
as if it were the initiator. Therefore, the 
middle agent has to force the log (SPM PEND- 
ING state) in order to reliably assume the 
resync responsibility if it should terminate 
abnormally. The middle agents do not need to 
force the log to COMMITTED state since resync 
will re-establish this state if it is lost. 


DEALLOCATE_ABEND_* 


PS.SPS may receive DEALLOCATE_ABEND_*. Since 
PS.SPS for the abnormally terminating TP will 
back out all of the TP's local resources, the 
local PS.SPS treats these return codes as 
BACKED_OUT. 


RESOURCE_FAILURE_*, RECOVERY, AND HEURISTIC 
DECISIONS 


Recovery from conversation failure depends 
upon the state of the conversation at the 
time of the outage: 


1. If the conversation is under the control 
of the sync point manager, it attempts to 
recover from the failure by exchanging 
Compare States GDS variables with the 
remote sync point manager as part of 
resync processing. PS.SPS does this by 
issuing ALLOCATE specifying the LU resync 
service TP X'06F2' as the transaction 
program. See “Resynchronization Logic" 
on page 5.3-18 for the logic that is exe- 
cuted during this resynchronization 
effort. 


If resynchronization succeeds, PS.SPS 
absorbs the RESOURCE_FAILURE_* return 
code and returns from the SYNCPT or BACK- 
OUT verb with the appropriate SYNCPT or 
BACKOUT return’ code. PS gives’7 the 
RESOURCE_FAILURE_* return code to the TP 
on the next verb (other than SYNCPT and 
BACKOUT® ) issued against the failing 
conversation, thus making the sync point 
verb and the resource failure appear to 
have occurred in the reverse order. This 
is done for the convenience of the TP 
writer. A TP that is using protected 
resources can take advantage of this by 
issuing SYNCPT or BACKOUT whenever a con- 
versation failure return code is recog- 
nized. This gets the TP to a Known 


8 If SYNCPT and BACKOUT returned RESOURCE_FAILURE_* there would be no way to resynchronize 


short of an IPL to drive the resyne logic. 
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state: backed out to the last successful 
sync point call. Backed out state is 
arrived at when BACKOUT or SYNCPT is 
issued, after a resource failure, because 
a resync occurs. In this case, resync 
can only lead to backed out. The TP can 
then perform its own recovery logic from 
a known state, greatly simplifying the 
TP's recovery logic. 


Because a new session may not be imme- 
diately available, the sync point manager 
and the lock manager have a _ protocol 
boundary that provides a capability to 
free locks on resources that may be 
needed by other TPs. When the lock man- 
ager needs to release locks, PS.SPS uses 
the guidance provided by the TP's entry 
in the transaction program list in RM, 
the LU control operator, or a programmed 
operator. The choices are either to hold 
the locks or to choose to do a partial 
commit or a partial backout of those 
resources with which communication has 
been maintained. The guidance (not shown 
in this book) indicates whether commit- 
ting, backing out, or holding the locks 
is to be performed when the TP fails and 
the lock manager needs to release locks. 
As PS.SPS makes this decision with only 
partial information, it is called a 
heuristic decision. 


BACKOUT PROCESSING 


5.3-16 


When processing the BACKOUT verb, PS.SPS 
causes all protected resources in the LUW to 
be restored to their condition at the start 
of the LUW. The exception is that protected 
conversations are not deallocated, and the 
remote TPs that they started are not termi- 
nated by backout processing. 


Like SYNCPT, BACKOUT is propagated to all TPs 
associated with the LUW. Also like SYNCPT, 
BACKOUT propagation requires all transaction 
programs that share a distributed unit of 
work to participate by issuing verbs, 1.e., 
BACKOUT. 


When a transaction program is notified of a 
BACKOUT initiated by another transaction pro- 
gram, the remote BACKOUT is complete. That 
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PS.SPS reports the resource state (which- 
ever is_ chosen; 
HEURISTIC RESET) to the LU control opera- 
tor (since the heuristic decision may 
result in a loss of synchronization among 
- the distributed resources that has to be 
repaired by operator action) and saves 
the state for comparison during resyn- 


chronization. The PS.SPS that is respon- 
sible for  resync continues resync 
attempts until resync completes. At this 


time, PS.SPS writes another message to 
the LU control operator and erases the 
LUN's log entries. 


2. If the conversation is not under the con- 
trol of the sync point manager, the 
responsibility for recovery is the trans- 
action program's. However, if sync point 
1s in use, the TP can typically turn the 
recovery processing over to the = sync 
point manager by using the SYNCPT or 


BACKOUT verb as soon as any desired proc= | 


essing has been. completed. Resources 
that are not protected are cleaned up 
according to application program logic. 
A failure by one TP or the other to 
return control to the sync point manager 
can lead to an extended holding of locks 
on shared resources. It may also lead to 
heuristic decisions if the locks have to 
be broken. 


HEURISTIC COMMIT or C 


—_ 


\ 


See ee 


is» the conversation resource that reports 
BACKED_OUT has already done so. The return 
code indicating this, BACKED_OUT, may be 
returned on several of the verbs. No backout 
of other resources in the local unit of work 
has been done. The TP must issue BACKOUT 
before it issues any other verb against pro- 
tected resources. 


ome, 


i ms 


Of particular interest is the case where: 
BACKOUT is issued in the midst of SYNCPT 
processing. The locally issued BACKOUT takes 
precedence over the SYNCPT requested by the 
remote TP if the LUW stays intact. See Fig- 
ure 5.3-12 and Figure 5.3-13 for examples 


that illustrate how this is accomplished. 
For brevity, the Forget commands are not 
shown. 


ba aa 


Committed Sequence Backed Out Sequence 1 Backed Out Sequence 2 
1. A —> B — Prepare 1. A -—> B — Prepare 1. A -—> B — Prepare 
z2. B -—> C — Prepare 2. B —> C — Prepare 2. B —> C — Prepare 
3. B —> D — Prepare 3. B —> D — Prepare 3. B -> D — Prepare 
4. C —> B — Request Commit 4. C —> B — Request Commit 4. C —> B — Request Commit 
5. D —> B — Request Commit 5. D —> B — Backed Out 5. D —> B — Request Commit 
6. B —> A — Request Commit 6. B —> C — Backed Out 6. B —> A — Request Commit 
a 7. A -—> B — Committed 7. B —> A — Backed Out 7. A -—> B — Backed Out 
\ 8. B —> C — Committed 8. B -—> C — Backed Out 
& 9. B —> D — Committed 9. B —> D — Backed Out 
STATUS = Committed STATUS = Backed Out STATUS = Backed Out 
Figure 5.3-12. Back Out Example 1 
CO 
Committed Sequence Backed Out Sequence 1 Backed Out Sequence 2 
1. A —> B — Prepare 1. A —-> B — Prepare 1. A -> B — Prepare 
2. A —-> C — Prepare 2. A -—-> C — Prepare 2. A-> C — Prepare 
3. B —> A — Request Commit 3. B —> A — Request Commit 3. B —> A — Request Commit 
4. C —> A — Request Commit 4. C —> A — Backed Out 4. C —-> A — Request Commit 
5. A —> D — Request Commit 5. A —> B — Backed Out 5. A —> D — Request Commit 
6. D —> A — Committed 6. A —> D — Backed Out 6. D —> A — Backed Out 
7. A —> B — Committed 7. A —> B — Backed Out 
8. A -—> C — Committed 8. A —> C — Backed Out 
STATUS = Committed STATUS = Backed Out STATUS = Backed Out 


Figure 5.3-13. Back Out Example 2 
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HEURISTIC DECISIONS AND RELIABLE RESOURCES 


Each implementation of the sync point option 
set makes available to transaction programs 
at least one protected resource that is fully 
reliable in that it is not subject to 
heuristic decisions. This can be done in a 
variety of ways; the simplest is to allow 
application designers to designate certain 


RESYNCHRONIZATION LOGIC 


5.3-18 


Resynchronization logic involves these steps: 


¢ If an IPL has occurred, RM retrieves log 
records from the log manager and recon- 
structs the protected TCBs and RCBs that 
were active at the time of the failure. 
It then causes PS.SPS to gain control on 
the reconstructed TCB. PS.SPS uses the 
log to restore its relevant states. For 
instance, it restores the initiator/agent 
state for each resource. PS.SPS also 
supplies log records to the protection 
managers for each resource so that they 
can back out their resources if this is 
required. 


e When PS.SPS finishes resynchronizing, RM 
deallocates the TCB. 


e If the resync is occurring without an 
IPL, PS.SPS will return control to the TP 
or to the abnormal termination process- 
or,» depending on the caller. The abnor- 
mal termination processor, of course, 
will deallocate all resources as needed. 


® Since it can happen that multiple conver- 
sations connect TCBs with the same LUWIDs 
in two separate LUs», resynchronization 
uses the value in the Conversation 
Correlator field carried in Attach (see 
SNA Formats) to uniquely identify the LUW 
whos states are to be compared. For 
example, this case occurs when TPa at LUa 
allocates a conversation with TPb at LUb. 
Then, as part of the same LUW, TPb allo- 
cates a conversation with TPc at LUa. 
The conversation correlator provides a 
way for PS.SPS at LUa to distinguish the 
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resources as not subject to heuristic deci- 


sions. However the reliable resource is pro- 
vided, application designers can use data 
kept in the reliable resource to aid in 


recovery from any heuristic mismatches that 
may occur. 


part of the LUW that LUa initiated from 
the part that LUb initiated. The conver- 
sation correlator is unique in a network. 
To provide uniqueness, the fully quali- 
fied LU name of the LU that created the 
conversation correlator is concatenated 
to the conversation correlator when com- 
parisons are made. The fully qualified 
LU name of the partner LU is Known from 
the system definition of the PARTNER_LU 
data structure. 


The decision to initiate resync by either end 
is depends upon the state of the unit of 
work. The following table reflects the 
action PS.SPS takes after a conversation 
failure or an IPL of the LU. 


UNIT—OF—WORK STATE ACTION BY PS.SPS 
(in local log) 


Not Found.......... No Action 


Agent, not last ... Wait for resync 
Agent, last ....... Resync after time-out 
Initiator ......... Initiate resync 


VALIDATION OF LOG IDS 


The first level of resynchronization is the 
validation of the log IDs. PS.SPS accom- 
plishes this by exchanging Log ID GDS vari- 
ables. When this exchange validates the 
integrity of the LU pair's logs, PS.SPS 
exchanges Compare States. The following fig- 
ures illustrate this resync logic. 


nic. 


¢ 
N 


(1) SYNCPT 


<——————-Session Outage Notification 


ALLOCATE same LUWID as the LUW that is being resynchronized 


SYNC_LEVEL( CONFIRM), 
TPN(X'O6F2') ... 5 


BIND 
| > (optional ) 
Attach 
SEND_DATA Exchange Log Name, log status (warm), log name (log name) 
| SSS SS rrr RECEEVE. ANDUWALT 
C_ SEND_DATA Compare States command, CD (2) 


RECEIVE _AND_WAIT < 
(2) Compare States reply, CD 
RECEIVE_AND_WAIT < 


DEALLOCATE 
TYPE(SYNC_LEVEL ) LUSTAT(X'0006'), RQD2, CEB 


(3) +DR2 


—~ r | < 
\ 
! 
es 


Figure 5.3-14. Resync after Conversation Failure 


The following notes correspond to the numbers 
in Figure 5.3-14. 


1. The TP issues SYNCPT or BACKOUT, giving 

PS.SPS_ control. Conversation failure 

results from the session outage. PS.SPS 

‘ detects this and begins resynchronization 
Ly by issuing ALLOCATE specifying the resync 
: : transaction program, X'06F2', as the TPN. 
The optional BIND may ‘flow between LUs as 
a result of RM logic; RM will send BIND 
to activate a new session if an existing 
session is not available; PS.SPS does not 
know if it flows. PS.SPS retrieves the 


> RECEIVE_AND_WAIT 


Exchange Log Name» log status (warm), log name (log name) SEND_DATA 


SEND_DATA 


> RECEIVE_AND_WAIT 
(3) 
CONFIRMED 


LUNID carried in this Attach from the 
TCB. 


PS.SPS validates the log name and then 
executes resync logic. Each conversation 
to be resynchronized is processed in a 
separate resync conversation using a sep- 
arate copy of the resync TP. 


PS.SPS tells the log manager to erase the 
LUN's log’ records. The half-session 
sends an LUSTAT because there is no data 
to send. The LUSTAT carries the RH. 
PS.SPS is not aware of this detail. 
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(1) 


LU fails 
ALLOCATE same LUWID as the LUW that is being resynchronized 
SYNC_LEVEL(CONFIRM), 
TPN(X'O6F2" ) coe § 
BIND 
> 
Attach 
> 
SEND_DATA Exchange Log Name, log status (warm), log name (log name) 
> RECEIVE_AND_WAIT 
SEND_DATA Compare States command, CD (2) 


(2) Compare States reply, CD 


RECEIVE AND_WAIT < 


DEALLOCATE 


TYPE(SYNC_LEVEL ) 


Figure 5.3-15. 


5.3-20 


LUSTAT(X'0006'), RQD2, CEB 


(3) +DR2 
< 


Resync after LU Failure 


The following notes correspond to the numbers 
in Figure 5.3-15. 


1. The LU fails. After the LU is IPLed, RM 
reads the sync point records from the 
log, rebuilds the TCB and RCBs, and gives 
PS.SPS_ control. After re-establishing 
the states of the local protected 
resources in cooperation with their pro- 
tection managers, PS.SPS proceeds’ to 
resync each LUW-in a separate conversa- 
tion, since the reply can be delayed 


while cascaded resync occurs. If all the 
resync conversations are processed in 
parallel, multiple sessions will be 


used--up to one per LUW to be resynchro- 
nized. This can cause as many BINDs as 
LUNs that are in resynchronization. A 
UPM determines the degree of parallelism. 
The more parallelism, the more session 
resources will be used, but the resync 
may complete faster. 
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> RECEIVE_AND_WAIT 


Exchange Log Name, log status (warm), log name (log name) SEND_DATA 
RECEIVE_AND_KALT <——————————————————_——_—_—— 


SEND_DATA 


> RECEIVE_AND_WAIT 
(33 
CONFIRMED 


2. PS.SPS validates the log name and then 
executes resync logic. 


3. PS.SPS erases the log. If a conversation 
or LU failure occurs during resynchroni- 
zation, PS.SPS repeats resynchronization 
until both logs are erased. 


SESSION OUTAGE DURING ATTACH 


If session outage occurs, the Compare States 
command that is part of resync can arrive 
ahead of the session outage notification. 
When this occurs and the last-resource opti- 
mization is being used, and if no special 
steps were taken, the result could be that 
one partner backs out and the other partner 
commits. The resolution of this race condi- 
tion is depicted in Figure 5.3-16 on page 
5.3-21. 


° PS.SPS(1) 


(1) 


(2) 


ALLOCATE 
SEND_DATA *BB, Attach, data, Request Commit, CD 
SYNCPT 
SON SON 
o—  ————— Xx 
BB, Compare States(Session ID) 
UNBIND( cleanup ) 
< 
Not Found 
< 
Ns NOTES: 


(3) 


> (4) 
DEACTIVATE_SESSION 
TYPE (CLEANUP ) 
SESSION_ID(Session ID) 


> (purged) (5) 
> (purged) 


(6) 


This shows how the failure is prevented by deactivating the session prior to 
processing the Compare States command. 


PS.SPS(1) is the PS.SPS instance that 1s running on behalf of the application TP. 
PS.SPS(2) 1s the PS.SPS instance that 1s processing the Compare States command. It is 
using a different session from that used by the application TP. 


Internal flows are not shown. 


--~. Figure 5.3-16. 
*. 
er 


The comments below correspond to the numbers 
in Figure 5.3-16. 


Ly 


A transaction is allocated with a sync 
level of sync point. 


Data is sent and a sync point (in this 
case, for an optimized last resource) is 
requested. 


After the data and Request Commit are 
sent, a session outage occurs. Both 
sides of the conversation are informed of 
the outage. 


When the sync point manager receives the 
outage indication, it sends a Compare 
States command (Exchange Log Name also 
flows but it is not shown in the dia- 
gram). This flows on a different session 
from the transaction program data. This 
session can use any mode. However, the 
performance characteristics of the mode 
should be good enough to avoid undue 
delays in resynchronization. As a result 
of using a different session, the Compare 
States command can arrive ahead of the TP 
data. 


To resolve this race condition, the 
receiving sync point manager, PS.SPS(2), 
issues a DEACTIVATE_SESSION TYPE( CLEANUP ) 
whenever Compare States is received. The 
Session Instance Identifier field of the 
Compare States command has the session 
identifier, to allow the sync point man- 


Avoiding Failure Resulting from an Attach-SON Race 


ager to deactivate the affected session. 
When the session deactivation is com- 
plete, any Attaches that are in transit 
are discarded and RM purges any records 
received from that half-session. Then 
the Compare States processing can pro- 
ceed. If the Attach has been processed 
and the attached TP executed before the 
deactivation is complete, a log entry for 
the LUW will be found. If the Attach is 
discarded, no log entry will be found. 
In either case, both data bases will 
remain synchronized. 


5. Depending upon when the Attach and SON 
arrive, either path control, RM or LNS 
purges them because the session has been 
deactivated. 


6. The receiving sync point manager, 
PS.SPS(2), checks the log for awareness 
of the LUW for which the Compare States 
was sent. Since the Attach has not 
arrived yet, or it was purged, no log 
entry exists. The reply to Compare 
States is therefore Not Found. 


It is possible that the incoming Attach has 
been processed and the PS process for the 
application TP was created, but the TP has 
never been dispatched when the Compare States 
arrives. In this case, the Attach arrives 
ahead of the Compare States, but as a result 
of timing conditions in the node, the Compare 
States TP (shown above as PS.SPS(2)) executes 
before the attached application TP. Then; 
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Figure 


5.3-22 


before the application TP runs and the LUW is 
logged, the half-session is deactivated 
because of the Compare States processing. 
When the DEACTIVATE_SESSION processing is 
completed, PS.SPS(2) checks the log to find 
the state of the LUW. The LUW is not logged 
yet, so the reply to the Compare States is 
Not Found. In order to avoid having the 
application TP execute later and commit the 
LUN, the sync point manager that is running 
on behalf of. an application TP checks that 
the LUW was not previously backed out, 
because of a session deactivation, before it 
commits. This is accomplished by having RM 
inform the sync point manager that the 
half-session it is using was deactivated. 
The sync point manager cannot perform a Com- 
mit if it is informed of a session deacti- 
vation. 


LOST SYNC POINT MESSAGES 


The logic for resync is summarized in Fig- 
ure 5.3-21 on page 5.3-26 through Fig- 
ure 5.3-25 on page 5.3-30. This logic is 
derived from Figure 5.3-19 on page 5.3-24,; 


SEND_ERROR 
Prepare 


< 
(purged )< 

Prepare 
(purged )< 
> 


5.3-17. 


When one TP issues SEND_ERROR followed by 
SYNCPT and messages are lost because of ses- 
sion outage, it is possible that both part- 
ners are the sync point initiator. In this 
case, each reports its state on the Compare 
States reply as if it were an agent. 


The one exception to this rule is in the case 
shown in Figure 5.3-18 on page 5.3-23. In 
this case, when resynchronizing, the original 
sender of Prepare (sync point services[1]) 
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which shows the sync point messages that can 
be lost because of session outage, as viewed 
by the initiator. For example, when a Pre- 
pare is lost because of SON, the state of the 
LUN at the sender of the Prepare (the initi- 
ator), is either SPM PENDING or HEURISTIC 
RESET; the state of the LUW at the receiver 
(the agent) is either RESET or PGM PENDING. 
In the case when SEND_ERROR and Prepare are 
lost from one TP and Prepare is lost from the 
partner, the state of LUW on either side of 
the conversation is SPM PENDING or HEURISTIC 
RESET. Given this, it is possible to con- 
struct the tables that guide the resynchroni- 
zation actions that the sync point managers 
must take. 


Prepare vs. Prepare races (when both sides 
issue Prepare, and the flows cross), Prepare 
vs. Request Commit races, and Request Commit 
vs. Request Commit races also can occur as a 


result of races between session outage 
notification and SEND_ERRORs. 
An example is shown in Figure 5.3-17. 


SEND_ERROR and Prepare vs. Prepare Race during Session Outage 


recognizes that the partner is resynchroniz- 
ing (following SON, the partner (sync point 
services[2]) sent a Compare States command 
with a state indicator of IN DOUBT). The 
sender of Prepare then replies with a RESET 
state indicator on the Compare States reply. 


The details of resync, based on the state of 
the LUN is shown in the matrix in Fig- 
ure 5.3-19 on page 5.3-24 and the logic 
depicted in Figure 5.3-23 and Figure 5.3-24. 
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() 


Sync Point Message Lost] Initiator's State When Agent's State 
By Session Outage ~' It Initiates Resync When Resync Occurs 


Prepare [3] SPM PENDING | RESET | 
HEURISTIC RESET [1] PGM PENDING [2] 
Prepare vs. SEND_ERROR SPM PENDING | SPM PENDING | 
and Prepare [5] HEURISTIC RESET [1] HEURISTIC RESET [1] 


Prepare vs. SEND_ERROR SPM PENDING | IN DOUBT | 
and Request HEURISTIC RESET [1] HEURISTIC RESET [4] | 
Commit(last) [5] HEURISTIC COMMITTED [4] 
SPM PENDING | IN DOUBT | 
Request Commit HEURISTIC RESET [1] HEURISTIC RESET [4] | 
HEURISTIC COMMITTED [4] 
IN DOUBT | 
Committed COMMITTED HEURISTIC RESET [4] -_ 
HEURISTIC COMMITTED [4] q 
Request Commit( last) IN DOUBT | RESET | 
[3] HEURISTIC RESET [4] | PGM PENDING [2] 
HEURISTIC COMMITTED [4] 
Request Commit( last) IN DOUBT | SPM PENDING | 
vs. SEND_ERROR and HEURISTIC RESET [4] | HEURISTIC RESET [1] 
Prepare [5] HEURISTIC COMMITTED [4] 
Request Commit( last) IN DOUBT | IN DOUBT | | a 
vs. SEND_ERROR and HEURISTIC RESET [4] | HEURISTIC RESET [4] | ( | 
Request Commit( last) HEURISTIC COMMITTED [4] |HEURISTIC COMMITTED [4] Lae 
IN DOUBT | 
Committed( last) HEURISTIC RESET [4] | COMMITTED 
HEURISTIC COMMITTED [4] 
Notes: 
1. The LUW has been backed out as a result of a heuristic request from 
the lock manager. The initiator still owes resync to the agents. 
2. The PGM PENDING state is never visible during resync, since it 
is converted to RESET. —_ 
3. These rows assume that no Prepare vs. Prepare type races have occurred. : | 
4. Either HEURISTIC RESET or HEURISTIC COMMITTED can occur from IN DOUBT. ae 


5. The agent issues SEND_ERROR and a sync point message, making the 
agent also an initiator for this race. 


Figure 5.3-19. Lost Sync Point Messages: Initiator's View 
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-_ 


Pad 


Last Agent's State when| State of receiver of 
it sends Compare States| Compare States 
command command 


Lost Message 


COMMITTED [Note] RESET | COMMITTED | 


HEURISTIC COMMITTED 


Implied Forget 


Note: The last agent does not have to send this Compare States command unless it needs to erase its 
log. The last agent does have to remember the COMMITTED state if 1t does not receive Forget, either 
implied or as part of the initiator's resync or following its own resync. (See Figure 5.3-25 on page 
5.3-30 for further details.) It is not possible to eliminate entirely this responsibility of the 
last agent without coupling the sync point resync to a single session instance. If the sync point 
resync were restricted to a single session instance, session data on that session could be treated as 
an Implied Forget. 


Figure 5.3-20. Lost Messages for Sync Point: Last Agent's View 


RESYNCHRONIZATION ACTION synchronization Operator Messages". on page 
5.3-30 for a description of the messages sent 
to the LU control operator.) For example, in 


Figure 5.3-21 on page 5.3-26 through Fig- Figure 5.3-21 on page 5.3-26,) if the initi- 


ure 5.3-25 on page 5.3-30 show the indicated 
states that the sync point manager is either 
sending or receiving in the Compare States 
command, in relation to the action taken. 
The logic depicted in these diagrams is the 
logic needed to ‘implement resynchronization 
when an IPL has taken place or after an LU or 
a session fails. 


The top left-hand corner of the tables indi- 
cates the role the sync point manager has in 
the sync point exchange. In Figure 5.3-21 on 
page 5.3-26, Figure 5.3-23 on page 5.3-28, 
and Figure 5.3-25 on page 5.3-30 the 
left-hand column shows the state indication 
that is sent on the Compare States command. 
The top row shows the state that is indicated 
in the Compare States’ reply. In Fig- 
ure 5.3-22 on page 5.3-27 and Figure 5.3-24 
on page 5.3-29, the left-hand column shows 
the state that is indicated in the Compare 
States command. The top row indicates the 
state of the LUW at the receiver; this state 
1s indicated in the returned Compare States 
reply. 


The matrix entry for the column-row pair 
indicates the action to be taken based on the 
pair of state indications exchanged. The 
action to be taken includes changing the 
state of the LUW at the LU and/or sending a 
message to the control operator. (See "Re- 


ator finds the state of an LUW to be IN DOUBT 
on its log, it sends a Compare States command 
to the last agent, with the state indicator 
in the command set to IN DOUBT. If the ini- 
tiator receives a Compare States reply with 
the state indicator set to RESET, it backs 
out the LUW. If the Compare States reply 
indicates COMMITTED, it commits the LUW. If 
the Compare States reply indicates HEURISTIC 
MIXED, it either commits or resets the LUW, 
based on a heuristic decision. The heuristic 
decision taken depends on the transaction 
program's defined characteristics. When the 
heuristic decision is taken, the LU control 
operator receives message 3. 


Figure 5.3-21 on page 5.3-26 and Fig- 
ure 5.3-22 on page 5.3-27 show the actions 
when resynchronizing with the last agent. 
The last agent must be resynchronized before 
any not-last agents are resynchronized 
because the state indication the last agent 
returns on the Compare States command con- 
trols the state indication sent to any 
not-last agents. When a Request Commit is 
sent to the last agent, the state of the LUN 
at the initiator with respect to the last 
agent is IN DOUBT. No other resynchroniza- 
tion is possible until it 1s Known whether 
the state of the LUW at the last agent is 
RESET or COMMITTED. 
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\ INITIATOR 
\ RECEIVES RESET | HEURISTIC | HEURISTIC | HEURISTIC 
Ne 2 LOG ENTRY RESET [3] | COMMITTED MIXED 
\ NOT FOUND ; 
INITIATORN 
SENDS 


HR or HC [2] 
and 


MSG 3 


HEURISTIC 
RESET 


HEURISTIC 
COMMITTED 


HEURISTIC 
MIXED [3] 


Notes: 

1. All intersections with dots should not occur. States 1, 2, 4, and 7 are not possible at the 
initiator. Message ¢ is generated for the control operator if indications of states 2, 3, 5, or 
6 are returned by the last agent on the Compare States reply. 

2. The heuristic direction is taken from the TP definition table. The TP definition table is 
created when the TP is defined to the LU. The HR (HEURISTIC RESET) or HC (HEURISTIC COMMITTED) 
action applies to local resources and cascaded resources. HEURISTIC MIXED (HM) state is reported 
to the resync initiator on the Compare States reply. In the case where the resync initiator was 
a cascaded agent, HM is reported to the sync point initiator in a PS header (Heuristic Mixed) 


3. These state indications should never occur. 


Figure 5.3-21. Resynchronization Action: At Initiator, When Resynchronizing with the Last Agent 
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C | \ LAST 
ae \ AGENT HEURISTIC | HEURISTIC | HEURISTIC 
RESET [5] | COMMITTED 
AGENT \ NOT FOUND 
RECEIVES \ 


COMMITTED 
[5] 4 


HEURISTIC 


C RESET 
HEURISTIC 
COMMITTED | MSG 3 [4] 
HEURISTIC 
MIXED [5] 7 


Notes: 


3 


1 
es oie 


1. All intersections with dots should not occur. States 1, 2, %» and 7 are not possible at the 
amet initiator. Message 4 is generated if indications of states 2, 3, 5, or 6 are returned by the 


C ; last agent. 
af 


2. If resyne occurs while the last agent is still in SPM PENDING or IN DOUBT state, the agent defers 
sending the reply until it completes its cascaded protocol, which may include resynchronization 
with cascaded agents. [Eventually the last agent's state will resolve to RESET, COMMITTED, or 
HEURISTIC MIXED. The HEURISTIC MIXED state is reported when SON occurs on sessions with at least 
two cascaded agents and the control operator at one of the LUs causes the LUW to be put into a 
HEURISTIC RESET state, while the operator at the other LU causes the LUW to be put into a 
HEURISTIC COMMIT state. If there are no cascaded resources, the last agent changes the state of 
the LUN to reflect the state reported on the Compare States request. 


3. In these cases, the agent takes no action, except to erase its log (if the log entry was found) 
eta upon the completion of the resync flows. The end of the resync flows is defined by receipt of 
C LUSTAT(X'0006'), RQD2, CEB from the initiator, or receipt of +RSP(LUSTAT) from the agent. See 
: Figure 5.3-14 on page 5.3-19 and Figure 5.3-15 on page 5.3-20 for more details. 
G4. A HEURISTIC MIXED situation (described in Note 2) has been detected and is reported to the resync 
initiator on the Compare States reply. The HEURISTIC MIXED state indicator is not propagated to 
the cascaded agents. See Figure 5.3-23 on page 5.3-28 for this case. 


5. These state indications should never occur. 


Figure 5.3-22. Resynchronization Action: At Last Agent, When Resynchronizing with the Initiator 
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\ 


INITIATOR 
\ RECEIVES RESET | SPM HEURISTIC | HEURISTIC | HEURISTIC 
\ LOG ENTRY | PENDING RESET COMMITTED | MIXED [4] 
\ NOT FOUND 
\ 
INITIATOR \ 


RESET 


SPM 
PENDING [5] 2 


IN DOUBT [6] 3 


COMMITTED 
4 


HEURISTIC 


SENDS \ 
1 


RESET 


HEURISTIC 
COMMITTED 


HEURISTIC 
MIXED [6] 7 


Notes: 


1. 


6. 


All intersections with dots should not occur. States 2, 3, and 7 are not possible at the 
initiator. Message 4 is generated if an indication of state 2 or 3 is returned by the agent. 


If resyne occurs while the not-last agent is still in SPM PENDING or IN DOUBT state, the agent 
defers sending the reply until it completes its cascaded protocol, which may include 
resynchronization with cascaded agents. Eventually the not-last agent's state will resolve to 
RESET, COMMITTED, or HEURISTIC MIXED. The HEURISTIC MIXED state is reported when SON occurs on 
sessions with at least two cascaded agents and the control operator at one of the LUs causes the 
LUN to be put into a HEURISTIC RESET state, while the operator at the other LU causes the LUW to 
be put into a HEURISTIC COMMIT state. If there are no cascaded resources, the last agent changes 
the state of the LUW to reflect the state reported on the Compare States request. 


In these cases, the agent takes no action, except to erase its log (if the log entry was found) 
upon the completion of the resync flows. 


In all the HEURISTIC MIXED (HM) cases displayed in this matrix, while HEURISTIC MIXED is reported 
as a return code on the SYNCPT verb, HM is not propagated to agents. Rather, they are told the 
initial state of the initiator so that Message 3 is not issued for those agents that are 


synchronized with the initiator. This is illustrated by the following case: the initiator of 
resynchronization reports COMMITTED on the Compare States command, the agent has three protected 
cascaded conversations. The agent finds SPM PENDING on its log» so it initiates 
resynchronization with its cascaded agents. One of the cascaded agents reports HEURISTIC 


COMMITTED and the other reports HEURISTIC RESET on the Compare States reply. Rather than send a 
Compare States command indicating HEURISTIC MIXED to the third protected conversation, COMMITTED 
is reported. 


When the initiator is in SPM PENDING state, it has resync responsibility. However, it reports 
its state as RESET on the Compare States command. The SPM PENDING state indicates that a resync 
1s expected. If the state is actually RESET, no resync is needed. 


These state indications should never occur. 


Figure 5.3-23. Resynchronization Action: At Initiator, When Resynchronizing with the Not-Last Agent 
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\ *LAST 
\ AGENT 
~LASTNSENDS | (NOT FOUND ) 
AGENT \N 
RECEIVES \ 


HEURISTIC 
COMMITTED 


SPM 
PENDING 
C2] 


HEURISTIC 


SPM 
PENDING [4] 
2 


IN DOUBT 
[4] 3 
COMMITTED 
4 


HEURISTIC 
RESET 


HEURISTIC 
COMMITTED 


HEURISTIC 
MIXED [4] 7 


C) 1. All intersections with dots should not occur. States 2, 3, and 7 are not possible at 
/ 


initiator. Message 4 1s generated if they are received. 


MSG 3 MSG 2 MSG 3 


the 


2. If resyne occurs while the agent is still in SPM PENDING or IN DOUBT state, the agent defers 


sending the reply until it completes its cascaded protocol, which may include resynchroniza 


tion 


with cascaded agents. Eventually the not-last agent's state will resolve from SPM PENDING to 


RESET or HEURISTIC MIXED; or IN DOUBT will resolve to RESET, COMMITTED, or HEURISTIC MIXED. 


If 


there are no cascaded resources, the last agent changes the state of the LUW to reflect the state 


reported on the Compare States request. 


3. In these cases, the agent takes no action, except to erase its log upon the completion of the 


resync flows. 
G4. These state indications should never occur. 


Figure 5.3-24. Resynchronization Action: At Not-Last Agent, When Resynchronizing with the Initi 
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ator 


5.3-29 


Notes: 


SPM 
PENDINGI 2] 


HEURISTIC 
RESET[2] 


HEURISTIC 
COMMITTED 
[2] 


HEURISTIC 
MIXED [2] 


1. The last agent erases its log-upon receipt of the initiator's state indication. 


2. If the initiator is in any state other than RESET, both the last agent and the initiator ignore 


the state exchange that started from the last agent. 
sending of a Compare States command. 


perform the actual resynchronization. 


3. The last agent actually finds COMMITTED on its log. 
initiator has already sent the implied Forget, but the implied Forget was lost. 
initiator has no log record that 
After a period of time, 
responsibility. 


It sends RESET. 


RESET, it means there has been a resync race. 
resync is forthcoming. 


Figure 5.3-25. Resynchronization Action: 


5.3-30 


RESYNCHRONIZATION OPERATOR MESSAGES 


The syne point manager issues several mes- 
sages to the LU control operator. Messages 
can be sent to the operator at the following 
times: following session outage, during the 
log name exchange, and during the resync 
exchange. The parameters shown in parenthe- 
sis (such as TPN, for transaction program 
name) are passed in the message. In the mes- 
sages that follow, reference is made to a 
‘waiting unit of work’. <A waiting unit of 
work is an LUW for which resynchronization is 
necessary. Until the resynchronization is 
complete, resources may be locked and una- 
vailable for other computations. The order 
that the messages may occur in are shown in 
Figure 5.3-26 on page 5.3-3l. 


e MSG 1: =A heuristic decision has been 
made for transaction program name (TPN), 
process ID (PID), at time (TIME), and 
logical unit of work ID (LUWID). As a 
result, resources in LUs (LU name-1, LU 
name-2, ... » LU name-X) may be in incon- 
sistent states with respect to the local 
resource states. 


Operator Action: Take user-defined 
action, if any, to protect data integrity 
until the local and remote data can be 
synchronized. 


e MSG 2: Resources in LUs (LU name-1, 

» LU name-X), previously reported to be 
exposed to state inconsistency with 
respect to local resources for trans- 
action program name (TPN), process ID 
(PID), at time (TIME), logical unit of 
work ID (LUWID), have been found to be 
synchronized. 
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In this case, it is possible that the ( 


indicates that the initiator is responsible for the resync. 
if the initiator has not attempted to resync, the last agent takes 
If the initiator replies with any state indication other than 
The initiator has resync responsibility and the 


It was started, at the last agent, by the 
The state indication exchange started by the initiator will 


As a result, the 


Resync from Last Agent 


Operator Action: Reverse the 
user-defined action taken when MSG 1 was 
acted upon. a 
MSG 3: Resources in LUs (LU namel, ... »——" 


LU nameX), previously reported to be 
exposed to inconsistency with respect to 
local resources for transaction program 
name (TPN), process ID (PID), at time 
(TIME), logical unit of work ID (LUWID), 
have been found to be out of synchroniza- 
tion. 


Operator Action: Take user-defined 
action to resynchronize the local and 
remote resources. ; 


( 

( 
MSG 4: Protocol failure in resynchroni- “~~ 
zation logic during attempted resynchro- 
nization of transaction program name 
(TPN), process ID (PID), at time (TIME), 
logical unit of work ID (LUWID), conver- 
sation correlator (CID). The local state 
was state (state name), the remote state 
was state (state name). 


Operator Action: Make inquiries’ to 
determine the state of the resources. 
Take user-defined action to resynchronize 
the resources. Submit APAR report. 


MSG 5: Session failure (with LU name-i, 
mode name-j) at time (TIME), has resulted 
in a waiting unit of work for transaction 
program name (TPN), process ID (PID), 
with logical unit of work ID (LUWID) and 
conversation correlator (CID). This LUW~ ~ 
is coupled to other LUs (LU name-m,... 
LU name-n). ‘a 


Operator Action: Reactivate the session 
as soon as possible. 


Figure 
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Resynchronization 


MSG 6: The waiting unit of work identi- 
fied by transaction program name (TPN), 
process ID (PID), and logical unit of 
work ID (LUWID), reported at time (TIME)> 
is being committed. 


Operator Action: none. 


MSG 7: The waiting unit of work identi- 
fied by transaction program name (TPN), 
process ID (PID), and logical unit of 
work ID (LUWID), reported at time (TIME), 
is being backed out. 


Operator Action: none. 


MSG 8: Resources in LUs (LU name-l, ...> 
LU name-X), previously reported to be 
waiting for resynchronization with 


respect to local resources for trans- 
action program name (TPN), process ID 
(PID), at time (TIME), logical unit of 
work ID (LUWID), have been found to be 
out of synchronization. 


Operator Action: Take user-defined 
action to resynchronize the local and 
remote resources. 


MSG 9: The logical unit of work identi- 
fied by transaction program name (TPN), 
process ID (PID), at time (TIME), logical 
unit of work ID (LUWID), has been waiting 
for HHH hours and MMM minutes. Locks 
held by this’~ resynchronization = are 
enqueued by NN transactions. 


Operator Action: If desired, abnormally 
terminate the PID specified process. 
This will release locks and may result in 
heuristic mismatches when resynchroniza- 
tion does complete. 


A 


5.3-26. The Sequence of LU Control Operator Messages Generated by Sync Point 


e MSG 10: LU (LU name) has returned an 
abnormal reply to the Exchange Log Name 


command. This LU has’7~ detected a 
warm/cold mismatch, or a log name mis- 
match. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for some waiting units of work. 


e MSG ll: A cold start has been attempted 
by LU (LU name), but the local LU has 
logical units of work that are awaiting 
resynchronization from the previous acti- 
vation. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for the waiting units of work. 


e MSG 12: LU (LU name) does not have the 
Same memory as does the local LU of the 
previous activation between them. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for the waiting units of work. 


ORDER OF RESYNCHRONIZATION 


When ae distributed unit of work fails 
because of a session or LU failure, more than 
one resynchronization exchange may be needed 
before resynchronization is complete. Fig- 
ure 5.3-27 on page 5.3-32illustrates what can 
happen. 
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Figure 


LOG NAME 


5. 3-32 


Resync flows 


Prepare 
< 
Request Commit Request Commit 
> 
(B Fails) 
< 
Resync flows 
> 
5.3-27. Cascaded Resynchronization Example 
The rule illustrated in the figure is the 
following: The initiator resolves in-doubt 


resources before it resynchronizes with the 
other resources involved in the logical unit 
of work. One result can be that some partic- 
ipants in the distributed LUW will make 
heuristic decisions. 


ERRORS AND FAILURES DURING RESYNCHRONIZATION 


Errors and additional failures can occur dur- 
ing attempted resynchronization. Repeated 
conversation failures are handled by the 
resynchronization logic, since log records 
are not erased until after the state indi- 
cations have been exchanged; see _  Fig- 
ure 5.3-14 on page 5.3-19 and Figure 5.3-15 
on page 5.3-20 for ‘examples. Errors that 
occur while the sync point manager has con- 
trol, such as completion of the receive timer 
that is started when resynchronization 
begins, are mapped into conversation fail- 
ures, created by UNBIND, thereby falling back 
into an error’ recovery loop (described 
below). 


The conversation failures, created by UNBIND, 
to recover from errors detected while the 
sync point manager has control are 
UNBIND(X' FEQ8640002' | X'FE08640001' ) depend- 
ing on the error—timer or logic’ error, 
respectively—rather than DEALLOCATE( ABEND), 
since the latter is not guaranteed to work 
under double failures (the receiver of DEAL- 
LOCATE has to continue to issue RECEIVE in 
order for it to work). 


PROCESSING 


The following two figures illustrate the 
processing of log names so that log mis- 


The error recovery process is described as a 
loop because it iterates until one of the 
loop exit conditions is satisfied. The error 
recovery loop has two exits: Either (1) the 
resync completes, or (2) the control opera- 
tor, after being informed that the resync 
attempt has been going on for a long time 
(the resync timer completes), decides to 
abnormally terminate processes that are hold- 
ing locks for this LUW rather than continue 
with the sync point manager resync attempts. 
The cleanup transaction will erase the log 
record after writing suitable messages to the 
error log. It may additionally force 


(unilaterally change, without agreement among \.__” 


partners ) the states of any pending 
resources, to HEURISTIC RESET or HEURISTIC 
COMMITTED, in the same way that heuristic 


decisions may force states. 


RESET STATE AND ERASING OF LOG RECORDS 


Reset state of the LUW (equivalent to unit of 


work backed out) is denoted by the absence of ~ >. 


a log record. 


The initiator's side can erase its log when 
all Forget flows have been’ completed, 
because, at this point, it is Known that 
resync will never be required. Therefore the 
question of ambiguity of no record found nev- 
er arises.? 


The slaves erase their logs before sending 
Forget, so that a subsequent failure that 
results in the loss of the Forget will result 
in a resync that finds no log record. 


matches do not occur. A log mismatch occurs 


if the LU control operator mounts the moO | 


The ambiguity is that not finding a log record could mean that the LUW has either not been 


logged yet (not started), or is committed (completely finished). 
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use the wrong log-dataset, or the LU IPLs and 


CO sync-point-log tape or instructs the LU to 


no log exists (this is referred to as a cold 


start). 


When this happens, the sync-point 


(1) LU IPLs Cold 


(2) 


(3) 


(4) 


ALLOCATE new LUWID, 
SYNC_LEVEL(CONFIRM), 
TPNCX'O6F2') ... 

BIND 
Attach 


Exchange Log Name, log status(cold), CD 


Exchange Log Name, log status(cold), RQDZ2, CEB 
< 


+DR2 


C Figure 5.3-28. Cold Start of an LU 


The following notes correspond to the numbers 
in Figure 5.3-28. 


1. 


The LU IPLs cold, that is» with a new log 
tape or new log dataset. No resync 
attempt occurs, since the log is empty. 
If the name of the LU's log.is changed, a 
cold IPL 1s required. 


PS.SPS is given control before any con- 
versations with SYNC_LEVEL(SYNCPT) are 
allocated in order to exchange log names 
with PS.SPS in the partner LU. The sync 
point manager needs to Know the partner's 
log name so log mismatches can be 
detected during resynchronization. 


log is not available for resync processing. 
The Exchange Log Name command is sent before 
the Compare States command, to detect a log 
mismatch. 


The resync TP, X'O6F2', accepts the cold 
log name and returns its own LU's log 
name. Message 11 might also be returned 
on an error reply, as_ shown in Fig- 
ure 5.3-29 on page 5.3-34. 


Upon logging the log name of the partner 
PS.SPS> PS.SPS tells RM that 
SYNC_LEVEL(SYNCPT) conversations can now 
be allocated to the partner LU. 


The partner PS.SPS similarly informs its 
RM. Race conditions can cause this 
transaction to be executed twice, once in 
each direction. 
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r] : 


(1) LU IPLs Warm, with wrong log (log can be a disk dataset or tape volume) 


ALLOCATE same LUWID as the LUW that is being resynchronized, 
SYNC_LEVEL( CONFIRM), 
TPN(X'O6F2') ... 


BIND 
> 
Attach 
rE A A EH 
Exchange Log Name, log status (warm), log name (log name) 
> a 
(2) Compare States, CD ( 
OOOO oe 
(3) Exchange Log Name(error reply), RQE1, CEB 
< 
Figure 5.3-29. Log Name Mismatch during Resync 
The following notes correspond to the numbers 3. PS.SPS sees the error reply and notifies 
in Figure 5.3-29. its control operator of the mismatch with 
Message 10. Conversations with 
1. The LU IPLs warm, but the wrong log vol- SYNC_LEVEL(SYNCPT) cannot be allocated _~ 
ume is active. However, RM and PS.SPS do between these LUs until the mismatch has | 
not Know this at first, and proceed with been fixed. Perhaps the correct volume. _ 
resync processing. can be activated; or the operator can use _ 
a cold IPL, although this may damage the 
2. The partner PS.SPS detects the mismatch consistency of protected resources. 


of log names, notifies its control opera- 
tor with Message 12, and returns an error 
reply. 
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C) 


ee USED BY SYNC POINT 


PS SPS 


FUNCTION: To coordinate sync point processing, as described in this chapter. Details 


are not formally specified. 


The sync point service is made up of a con- 
trolling subcomponent (PS.SPS) that deter- 
mines when presentation services’ headers 
should be sent, and a subcomponent (in con- 
versation resources protection manager 
[PS.CRPM]) that builds and sends the sync 
point headers. The subcomponents that build 
and send sync point headers are: 


1. PREPARE 


2. REQUEST_COMMIT 


3. COMMITTED 


4. FORGET 


5. HEURISTIC_MIXED 


The calling tree to show the relation of the 


components of sync point services is shown in 
Figure 5.3-30 on page 5.3-36. 


A high-level overview of these subcomponents 
is described below. 


PREPARE 


The presentation services header contains a 
field (1i.e., Syne Point Control Modifier) by 
which the receiver is requested to take a 
specific action upon completion of the sync 
point flows. This is done because the initi- 
ator issues SYNCPT when it is in either SEND 
state or DEFER state (see FSM_CONVERSATION on 
page 5.1-65). DEFER state is reached two 
ways: by issuing PREPARE_TO_RECEIVE or DEAL- 
LOCATE with TYPE(SYNC_LEVEL) when the sync 
level is SYNCPT. At the completion of the 
sync point flow, the sender of the last sync 
point command has send control; however, the 
TP may not need send control. Therefore, on 
the first command of the sequence, the Sync 
Point Control Modifier field of the PS header 
indicates the side of the conversation that 
is to have send control, or deallocation 
responsibility, after the last sync point 
command is sent. The Sync Point Control Mod- 
ifier can be set to the following values: 


Request RECEIVE: The sync point initi- 
ator requests to be in RECEIVE state upon 
completion of the sync point flow. 


Request DEALLOCATE: The sync point ini- 
tiator requests that a DEALLOCATE be 
issued upon completion of the sync point 


flow. 


Request SEND: The sync point initiator 
requests to be in SEND state upon com- 
pletion of the sync point flow. 


When PREPARE is issued, the CD and CEB indi- 
cators in PS's send buffer (see Chapter 5.1) 
may be in one of three combinations of set- 
tings: 


1. -CD and -CEB—neither PREPARE_TO_RECEIVE 
nor DEALLOCATE has been issued. 


2. CD and ~CEB—PREPARE_TO_RECEIVE has been 
issued. 


3.  7CD and CEB—DEALLOCATE has been issued. 


If in state 1 (-CD and -CEB), a PS header 
(Prepare) with modifier Request SEND is 
placed in the send buffer. The RQE1, CD, and 
EC indicators are turned on and the send 
buffer is sent to DFC. The Prepare then 
requires a reply. The reply will be either a 
PS header (Request Commit | Forget) or a 
-RSP. If a PS header is received, PREPARE 
subcomponent returns with a REQUEST_COMMIT or 


FORGET return code. It can also return 
RESOURCE_FAILURE (it 1s not a 
resource-specific verb). If a PS header, 


~RSP(0846), or resource failure is not pres- 
ent, a fatal error has occurred and the ses- 
sion is deactivated (using X'FE' reason code 
and appropriate UNBIND sense code). If a 
~RSP(0846) is received, the next data to 
arrive on the session is an FMH-7 and the 
return code is set according to the FMH-7 
sense data. 


If in state 2 (CD and -CEB), a PS header 
(Prepare) with modifier Request RECEIVE is 
placed in the send buffer. The RQE1, CD, and 
EC indicators are turned on and the send 
buffer contents are transmitted to DFC. The 
PREPARE subcomponent then requires a reply. 
A PS header indicates a successful Prepare; 
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SYNC POINT MANAGER 
(PS.SPS) 


CONVERSATION RESOURCE 
PROTECTION MANAGER 


(PS.CRPM ) 


PREPARE REQUEST COMMITTED FORGET HEURISTIC RESYNC 
COMMIT MIXED [f | = [eeeen----- > 


Note: 


Figure 


5.3-36 


RESOURCES MANAGER 
(RM) 


RESYNC TP 
(X'O6F2" ) 


All relationships are via Call and Return except for the RESYNC TP, 
which is invoked as a remote service transaction program. 


5.3-30. Syne Point Services Calling Tree 


the return code is set accordingly. If a 
-RSP(0846) is received, the next data to 
arrive on the session is an FMH-7 and the 
return code is set accordingly. 


If in state 3 (-CD and CEB), a PS header 
(Prepare) with modifier Request DEALLOCATE is 
placed in the send buffer. The RQE1, CD, and 
EC indicators are turned on and the send 
buffer contents are transmitted to DFC. The 
PREPARE subcomponent then requires a reply. 
A PS header indicates a successful Prepare; 
the return code is set. If a -RSP(0846) is 
received, the next data to arrive on the ses- 
sion is an FMH-7 and the return code is set 
accordingly. 


REQUEST_COMMIT 


As for Prepare, PS's send buffer may be in 
the same three states when Request Commit is 
sent. Additional information is also Known. 
PS.SPS and PS.CRPM Know whether or not the 
current Request Commit is being sent in reply 
to a Prepare. PS.CRPM uses the information 
to build the PS header. PS.SPS Knows whether 
or not changes have occurred in_ other 
resources for this LUN. 


When Prepare has not been received, these 
cases apply: 


1. When in state 1 (-CD and -CEB), the 
REQUEST_COMMIT subcomponent causes PS 
header (Request Commit, Request SEND) to 
be transmitted and waits for the reply. 
If Committed is received, REQUEST COMMIT 
completes normally; however, if a 
-RSP(0846) 1s received, REQUEST_COMMIT 
processing waits for the FMH-7 and com- 
pletes with the appropriate return code. 
Session outage is indicated in the return 
code for REQUEST_COMMIT as resource fail- 
ure. 


2. When in state 2 (CD and -CEB), the 
REQUEST_COMMIT subcomponent causes a PS 
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header (Request Commit, Request RECEIVE ) 
to be sent. The reply will be either 


Committed, SON, or aie -RSP(0846) and 
FMH-7. The appropriate return code is 
set. 

3. When in state 3 (-CD and CEB), the 


REQUEST_COMMIT subcomponent causes a PS 
header (Request Commit, Request DEALLO- 
CATE) to be sent. The COMMITTED, SON, or 
-RSP(0846) and FMH-7 reply sets’ the 
return code. 


When Prepare has been received, one of these 
cases applies (PS.SPS chooses): 


1. Changes have occurred in local or cas- 
caded resources. PS header (Request Com- 
mit, Request SEND) is sent and the return 
code set according to the reply. 


2. No changes have occurred in either local 
or cascaded resources. 
manager does not 
Forget is sent next. 


send Request Commit; 


COMMITTED 


Committed is sent by PS.SPS as a reply to 
Request Commit. Committed is sent with RQEl; 
CD. No Sync Point Control Modifier is sent. 
If Committed is sent from the last resource, 
CD and CEB are set by PS.CRPM as specified in 
Sync Point Control Modifier from the previous 
Request Commit. 


FORGET 


Unlike the case for the PREPARE and 
REQUEST_COMMIT subcomponents, the send buffer 
1s in a Known state when Committed and Forget 
are sent. The FORGET subcomponent uses the 
information passed on the Sync Point Control 
Modifier field of Prepare to leave the con- 
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The syne point ~~. 
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versation in the state desired by the trans- 
action that initiated SYNCPT. 


HEURISTIC_MIXED 


As in the case for FORGET, the send buffer is 
in a Known” state when Heuristic Mixed is 
sent. The  HEURISTIC_MIXED = subcomponent 
builds and sends the PS_ header(Heuristic 
Mixed) using the information passed on the 
Sync Point Control Modifier field of the Pre- 
pare to leave the conversation in the state 
desired by the transaction that initiated 
SYNCPT. 


The Heuristic Mixed PS header is sent when a 
sync point agent discovers that two or more 


C SESSION FLOWS CREATED BY SYNC POINT 


eo are I 


C | 
' 
f 
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The following illustrates the flows that can 
be generated by SYNCPT: 


om 
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cascaded agents have gotten out of sync after 
a failure and resync. This is illustrated in 
Figure 5.3-31 on page 5.3-38. In this dia- 
gram, conversation or session failures at TPb 
with TPc and TPd can lead to a heuristic 
decision at TPc that conflicts with the 
heuristic decision that is made at TPd. This 
can be avoided with properly defined failure 
recovery procedures for the LU control opera- 
tor. However, if heuristic damage occurs, it 
is discovered when TPb resyncs with TPc and 
TPd. Because no failure has occurred between 
TPb and TPa, no resync occurs on that conver- 
sation. The Heuristic Mixed PS header is 
used to inform the sync point initiator, TPa;> 
that a heuristic decision has caused damage 
in the distributed LUN. 


5.3-37 


SYNCPT flow TPc 
<<< > (cascaded agent) 
SON followed by resync | 
> 


a 


TPa SYNCPT flow TPb 
(sync point <—————>__ (sync point TPd 
initiator ) ; agent } SYNCPT flow (cascaded agent) 
<> 
SON followed by resync 
> 


PS Header(Heuristic Mixed) 
Fe EE Ee RT ee | 


Figure 5.3-31. Heuristic Mixed in Reply to Sync Point Flow 


TP(L) | TP(2) 
| | = 


SEND_DATA ae 
PREPARE_TO_RECEIVE ; 
SYNCPT 


7 RECEIVE_AND_WAIT 
data, Request Commit(Request RECEIVE), RQE1, CD WHAT_RECEIVED=DATA 


WHAT_RECEIVED=DATA 
RECEIVE_AND_ WAIT 
: WHAT_RECEIVED=TAKE_SYNCPT 
Committed, BC, -EC, -CD SYNCPT 
Fe er EE ee RC=0K 
(LUN STATE is COMMITTED) (~ 
a 4 


-or- ee 
SEND_DATA 
SYNCPT 
RECEIVE_AND_WAIT 
data, Request Commit( Request SEND), RQE1, CD WHAT_RECEIVED=DATA 
> 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=TAKE_SYNCPT 
Committed, RQE1, CD SYNCPT 
<< RC=0K tae 
(LUN STATE is COMMITTED) - 
-or- % 
SEND_DATA 
DEALLOCATE 
SYNCPT 


RECEIVE_AND_WAIT 

data, Request Commit(Request DEALLOCATE), RQE1, CD WHAT_RECEIVED=DATA 
> 
RECEIVE_AND_WAIT 
, WHAT_RECEIVED=TAKE_SYNCPT 
Committed, RQE1, CEB SYNCPT 
SS eee RC=0OK 
(LUN STATE 1s COMMITTED) 


Figure 5.3-32. Verb Sequences and Sync Point Flows to the Last Agent, Which Has No Cascaded 
Resources 


C 
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fos 
es TPC) TP(2) 


é RECEIVE 
SEND_DATA Serene ereneereerernianeee > RC=OK WHAT_RECEIVED=DATA 
; RECEIVE 
- 7 RC=OK WHAT_RECEIVED=DATA 
SEND_DATA data, Prepare(Request SEND), RQE1, CD RECEIVE 
SYNCPT ee RC=OK WHAT_RECEIVED=TAKE_SYNCPT 
SYNCPT 
Forget, RQE1, CD : 
terete RC=OK (LUW STATE is COMMITTED) 
RC=OK (LUW STATE 1s COMMITTED) 


Figure 5.3-33. Syne Point with No Resources Changed: The Request SEND on the Prepare is a command 

to send CD on the return flow. The transaction program is not given a chance to send 

Se any data or to influence the conversation states (other than to terminate 
C | abnormally). This Request SEND is not the RH CD indicator but is in the PS header. 


TP(1) TP(2) 


RECEIVE 
C SEND_DATA ———— SS RC=OK WHAT_RECEIVED=DATA 


; RECEIVE 
. RC=OK WHAT_RECEIVED=DATA 
‘ data, Prepare(Request SEND), RQE1, CD RECEIVE | 
SYNCPT SS RC=OK WHAT_RECEIVED=TAKE_SYNCPT 
Request Commit, RQE1, CD SYNCPT 


Committed, RQE1, CD 


Forget, RQE1, CD 
Gr, — "00 Oe RC=OK (LUW STATE is COMMITTED) 
C RC=OK (LUW STATE is COMMITTED) 
/ SEND_DATA 
‘ Data 
, : ——— 
RECEIVE 


Figure 5.3-34. Syne Point with Changes to Protected Resources, Request SEND: In this flow, the 
Prepare requests that the CD be returned (Request SEND) on the Forget. 
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TP(1) TP(2) C 


| RECEIVE 

SEND_DATA —_————— > __ RC=0K WHAT_RECEIVED=DATA 
; ; RECEIVE 

| RC=OK WHAT_RECEIVED=DATA 
PREPARE_TO_RECEIVE Data, Prepare(Request RECEIVE), RQE1, CD RECEIVE 


SYNCPT > ROOK 
WHAT_RECEIVED=TAKE_SYNCPT 


Request Commit, RQE1, CD 
eee SYNCPT 


Committed, RQE1, CD 


Forget, BC, -EC | 
—— RC=OK er. 


RC-OK (LUW STATE is COMMITTED) ( LUW STATE is COMMITTED ) 
RECEIVE 
data RC=SEND 


es SEND_DATA 


Figure 5.3-35. Sync Point with Changes to Protected resources, Request RECEIVE: The Request RECEIVE 
in Prepare indicates that the flow is to be reversed. The Forget is flushed to let 
locks be released. It is not necessary to flush the Forget if the TP is sure to 
generate application data right away. 


+ 


aa 
TP(1) TP(2) 
e RECEIVE 
SEND_DATA —_————__—_ nn mn —_ Ww > RC=OK WHAT_RECEIVED=DATA 
fe RECEIVE ( 
" " RC=OK WHAT_RECEIVED=DATA Se 
DEALLOCATE data, Prepare(Request DEALLOCATE}, RQE1, CD RECEIVE = 
SYNCPT > RC=OK WHAT_RECEIVED=TAKE_SYNCPT 
Request Commit, RQE1, CD | SYNCPT 
Pe A aE IO an Ce a EE ee re ee 
Committed, RQE1, CD 
> RC=OK (LUW STATE is COMMITTED) 
RECEIVE 
RC=DEALLOCATE_NORMAL 
Forget, CEB, RQE1 
—_—_—_—_—_—_—_—_—_—_—_————__————___—___——_—KKKxKxKxKxKXK DEALLOCATE 
local deallocation 
local deallocation : 
RC=OK (LUW STATE is COMMITTED) 
Figure 5.3-36. Syne Point with Changes to Protected Resources, Request DEALLOCATE: The Request 
DEALLOCATE in the PS header (Prepare) is a command to send CEB on the return flow. 
The transaction program is not given a chance to send any data or to influence the 
conversation state if the sync point completes normally. If BACKOUT or a negative 
response is received, the transaction program is not deallocated and the TP may issue ' 
BACKOUT. i. 
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SESSION FLOWS CREATED BY ERRORS DURING SYNC 
POINT 


All base error flows may occur. These 
include application errors, local resource 
failures, program failures,» session failures, 
conversation failures, and LU failures. See 
Chapter 2 for an explanation of the types of 
errors. Additionally, BACKOUT can be issued. 
This verb causes flows the same as SEND_ERROR 
(i.e., -RSP(0846) followed by FMH-7) except 


Issue PREPARE_TO_RECEIVE (FLUSH). 


Figure 5.3-37. BACKOUT Logic 


This has the advantage of propagating the 
backout even if the partner transaction has 
issued SEND_ERROR. It also handles send and 
receive state variations. 


The expansion shown above places responsibil- 
ities on the’ transaction’ programs: for 
instance, if entered while the partner has 
the CD bit and before the first RU of the 
chain arrives, it can hang in the SEND_ERROR 
for a long time. This’ is because the 
SEND_ERROR doesn't cause a -RSP to flow until 
a chain arrives. Transaction programs that 
issue BACKOUT must take the potential delay 
into account. It is the transaction pro- 
gram's responsibility to make sure that the 
delay has no undesirable results. If the 
BACKOUT process takes too long to complete, 
the session can be abnormally terminated. 
The LUW state will be repaired by resync 
processing. 


Abnormal termination after a BACKOUT verb 
results in several flows, but this is accept- 
able, since it is an error case. 


the FMH~7 is limited to carrying a sense code 
of X'0824' (Sync Point Manager Abort). BACK- 
OUT may be issued whenever a SEND_ERROR can 
be issued (1.e., it is independent of the 
send/receive state). 


BACKOUT 


The BACKOUT verb results in the sequence 
shown in Figure 5.3-37. 


Do until RC=0K|RESOURCE_FAILURE_*|BACKED_OUT|DEALLOCATE_x 
Issue SEND_ERROR with a sense code of X'0824¢’. 

Issue a CONFIRM verb (Backout flows RQD2]|3). 

If send control was at the other end at the last sync point 


Transaction programs that are cooperating 
with each other need to obey a discipline in 
issuing SYNCPT. A TP must be coded to issue 
SYNCPT when its partner TP expects a sync 
point request. However, because the CD bit 
is, in effect, a protected variable (1.e., it 
flows in the Sync Point Control Modifier 
field of the PS header and the sync point 
manager 1s responsible for maintaining the 
conversation in the proper state with respect 
to the CD bit) the TPs do not need to obey a 
convention for BACKOUT. BACKOUT may be 
issued in SEND, DEFER, RECEIVE, CONFIRM, SYNC 
POINT, or BACKED-OUT state. The SEND state 
is restored to the transaction that owned it 
at the completion of the last successful 
SYNCPT. For BACKOUT prior to the _ first 
SYNCPT call, the CD bit is restored to the 
Attach sender. 
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PRESENTATION SERVICES--CONTROL-OPERATOR VERBS 
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INTRODUCTION 


‘CONCEPTS 


& 


This chapter presents an overview of LU serv- 
ices for the LU control operator, and in par- 
ticular describes those services contained in 
the presentation services components of the 
LU and in LU service transaction programs. 


FUNCTION SUMMARY 


The control operator is represented to the LU 
by a control-operator transaction program 
which invokes operator functions by issuing 
LU-defined control-operator verbs. The 
relationship between the  control-operator 
transaction program and the control operator 
is implementation-defined and is not deter- 
mined by SNA. Throughout this chapter, the 
terms control-operator and control-operator 
transaction program are used synonymously. 


The control-operator transaction program dif- 
fers from application transaction programs in 
its focus on control-operator concerns and 
its privileged access to the control-operator 
verbs. 


The functions available to the control oper- 
ator and the control-operator verbs that 
invoke them are described in SNA Transaction 
Programmer's Reference Manual for LU Type 


6.2. That book is a prerequisite to this 
chapter. 


The control operator describes and controls 
the availability of certain resources. The 
particular functions and corresponding 
control-operator verbs are: 


e To describe the network resources 
accessed by the local LU, such as trans- 
action programs, partner LUs, and mode 
names. The relevant verbs are: 


AND TERMS 


This section describes some of the concepts 
and terms used throughout this chapter. 
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oe 


services 


= DEFINE 
= DISPLAY 


e To control the number of sessions between 
the LU and its partners. The relevant 
verbs are: . 


~ INITIALIZE_SESSION_LIMIT 
— RESET_SESSION_LIMIT 

—  CHANGE_SESSION_LIMIT 

— ACTIVATE_SESSION 

~ DEACTIVATE_SESSION 


¢ To invoke local processing on behalf of a 
control-operator verb issued at a remote 
LU. The relevant verb is: 


= PROCESS SESSION_LIMIT (This verb is 
not available to the local operator, 
but is issued from within the LU. ) 


STRUCTURE SUMMARY 


This chapter describes two LU components for 
control-operator functions: presentation 
for the control operator (PS.COPR), 


a component of presentation services, and the 
CNOS service transaction program (CNOS serv- 


ice TP). It also describes the functional 
relationship of these components to the 
installation- or imp lementation-def ined 


control-operator transaction program, to the 
LU resources manager (RM--see Chapter 3), to 
presentation services for conversations 
(PS.CONV--see Chapter 5.0 and Chapter 5.1), 
and to half-sessions (HS--see "Chapter 6.0. 
Half-Session"). 


Figure 5.4-1 on page 5.4-2 shows the struc- 
tural relationship of these components (see 
Chapter 2 for the complete structure of the 
LU). 


OPERATOR 


The control-operator transaction program is 
an implementation-defined transaction program 
that interacts with presentation services on 
behalf of, or in lieu of, a human operator. 
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Note: Unshaded components are described in this chapter. 


Figure 5.4-1. Control-Operator Components in Relation to Other Components of the LU 


The control-operator transaction program A control-operator verb is a privileged verb 
interacts with presentation services by issu- that may be issued by the control-operato~. 
ing control-operator verbs to control the LU transaction program to convey the operator 

or to control the interactions of the LU with request to the internal components of the LU. 
a partner LU. Control-operator verbs are described in SNA 
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Transaction Programmer's Reference Manual for 
LU Type 6.2. 


SCOPE OF CONTROL-OPERATOR FUNCTIONS 


LU control-operator-verb functions vary in 
scope. 


Control-operator local functions affect only 
that LU whose control operator issues the 
control-operator verb, or they affect a ses- 
sion with another LU but take effect without 
the concurrent participation of a 
control-operator transaction program at the 
other LU. These functions include describing 
LU-accessed resources, regulating the number 
of sessions with single-session LUs, and 
activating and deactivating specific ses- 
sions. 


Control-operator distributed functions affect 
the relationship between the LU at which the 
control-operator verb is issued (called the 
source LU) and another LU with which it 
shares one or more’ sessions (called the tar- 
get LU). The functions take effect only with 
the cooperation of transaction programs 
representing the control operators at the two 
LUs. These functions involve primarily regu- 
lating the number of parallel sessions with 
other LUs, including orderly increase from no 
sessions and decrease to no sessions; they 
are called change-number-of-sessions (CNOS) 
functions. 


A control-operator verb for distributed func- 
tions may be issued at either LU. Thus, the 
roles of source LU and target LU are relative 
to a particular verb issuance: a particular 
LU may be source LU for-one issuance and tar- 
get LU for another. 


LU-ACCESSED NETWORK RESOURCES 


The control operator describes to the local 
LU those network resources accessed from the 
local LU (LU-accessed network resources). 
The following resources are described. 


e The local LU itself 


e Transaction programs available for exe- 
cution at this LU 


e Partner LUs: The remote LUs with which 
this LU can have sessions 


e Modes: defined sets of characteristics 
for sessions with particular partner LUs 
(One or more modes are defined for each 
potential partner LU. ) 


The control operator also controls the number 
and availability of the following resources: 


e Sessions with particular partner LUs. 


Each LU resource is identified to the opera- 
tor either implicitly or by a resource Key 


such as a transaction program name, a partner 
LU name, a mode, name» or a session identifi- 
er. 


Each LU resource is described by the LU defi- 
nition that characterizes the way the LU can 
use it. For example, these include trans- 
action program characteristics such as avail- 
ability status and optional functions 
supported; LU capabilities such as parallel 
sessions; mode name attributes such as ses- 
sion limits, RU size bounds » and 
cryptography; and control point capabilities 
such as INIT (logon) formats supported. 


SESSION CHARACTERISTICS 
Session Identification 


Most control-operator verbs do not specify a 
specific session, but specify only the part- 
ner LU and mode name for the session; the 
implementation selects the particular ses- 
Sion. Some verbs, however, can reference a 
specific session by specifying an 
implementation-supplied unique session ID. 


Single vs. Parallel Sessions 


An LU can be characterized by the number of 
sessions it allows with other LUs. A 
single-session LU can have only one LU-LU 
session with a given partner LU. A single 
session LU may have more than one session 
concurrently, but each concurrent session is 
with a different partner. A parallel-session 
LU can have one or more concurrently active 
sessions with a given partner LU, subject to 
session limits discussed below. 


The term parallel session denotes any session 
between a pair of parallel-session LUs» even 
if only one such session is currently active. 
This contrasts with the term single session, 
which denotes a session between a pair of 
single-session LUs or between. a 
single-session LU and a parallel-session LU. 
A parallel session--even a solitary parallel 
session--uses protocols different from those 
used on a single session. 


Contention Polarity 


Sessions are also characterized by their con- 
tention polarity. This determines which of 
the two LUs has the right to control use of 
the session. If two LUs attempt to initiate 
a conversation on the same session simultane- 
ously, the LU that is contention winner for 
that session will succeed and the other, the 
contention loser, will fail. 


When used in reference to sessions, these 
terms are relative to the perspective of one 
of the LUs: a session for which an LU is the 
contention winner is called a 
contention-winner session from its perspec- 
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tive, but it is a contention-loser session 
from the perspective of the partner LU. 
Unless otherwise specified, the perspective 
used in this chapter is that of the LU at 
which a relevant control-operator verb is 
issued. 


SESSION LIMITS AND COUNTS 


The number of active sessions between two LUs 
fluctuates as a result of transaction program 
demand and explicit operator action. The 
number of sessions active at any given time 
is called the session count. 


The maximum number of sessions allowed 
between LUs is set dynamically by the LU 
operators. This number is called a session 
limit. Several session limits may be speci- 
fied by the operator. 


The total LU-LU session limit is the maximum 
number of LU-LU sessions allowed by the local 
LU. If this limit is 1, the LU is a 
single-session LU; if it is greater than l; 
the LU is a parallel-session LU. This limit 
regulates the total LU-LU session count. 


The operator can regulate the number of ses- 
sions between the LU and a particular partner 
LU, and hence the number of transactions that 
can be active concurrently using that pair of 
LUs. 


The (LU,mode)} session limit specifies the 
currently allowed maximum number of sessions 
with a specific partner LU using a specific 
mode name. This limits the corresponding 
(LU,mode) session count, i.e., the number of 
currently active sessions with that partner 
LU using that mode name. One such limit and 
count exist for each mode name that is 
defined for each potential partner LU. 


In this chapter, unless otherwise specified, 
the unqualified terms "session limit" and 
"session count" refer to the (LU,mode) ses- 
sion limit and count, respectively. 


For parallel-session connections, other 1lim- 
its regulate the (LU,mode) session count 
within the (LU,mode) session limit. 


The operator can assure that each LU can 
allocate a minimum share of the concurrent 
conversations by setting limits on session 
contention polarities. 


The local-LU minimum contention-winner limit 
1s the minimum number of sessions with a par- 
ticular (LU,mode) pair for which the local LU 
is allowed to be the contention winner; the 
partner-LU minimum contention-winner limit is 
the minimum number of sessions with that 
(LU,mode) pair for which the partner LU is 
allowed to be the contention-winner. When 
activating a session, each LU selects a 
contention-polarity for the session that is 
consistent with these limits, i.e., it does 
not encroach on the partner's allowed con- 
tention winner sessions. 
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The operator can specify that a certain num- 
ber of sessions be activated whenever the 
relevant limits allow, without waiting for 
explicit requests for each session. 


The automatic-activation limit is the maximum 
number of sessions that the local LU may 
activate in the absence of explicit requests 
from transaction programs or the operator. 


SESSION BRINGUP AND TAKEDOWN 
Phases 


The following four phases of session bringup 
and takedown activities exist, although some 
phases are omitted in some circumstances. 


Session-limit initialization and reset con- 
sists of issuing control-operator verbs to 
specify the number of sessions the LU can\ 


have with a given partner, and to specify ~ 


conditions for their activation and deacti- 
vation. 


Session initiation and termination consists 
of control-point activity that mediates 
requests for session activation and deacti- 
vation, such as issuing INITIATE (INIT_SELF) 
and CONTROL INITIATE (CINIT) or TERMINATE 
(TERM_SELF) RUs. 


Session shutdown consists of the LU activity 
to terminate conversation activity (brackets 


on the session by issuing BRACKET INITIATION...” 


STOPPED (BIS) RUs. 
Session activation and deactivation consists 


of exchanging the BIND or UNBIND request and 
response RUs between the LUs. 


Control-Operator Functions 


The operator can cause an orderly deacti- 
vation of sessions between a pair of LUs by\ 


specifying that the (LU,mode) session limits ~-~ 


be reset to 0. 


The operator can also specify whether to 
drain (1.e., satisfy) pending allocation 
requests before deactivating sessions. It 
can specify drain separately for each of the 
source and target LUs. If drain is specified 
for an LU, that LU continues using sessions 
until there are no further 
transaction-program allocation requests for a 
session. If drain is not specified, the LU 
shuts down and deactivates the sessions as 
soon as the current transactions finish. 


The operator can specify session-deactivation 
responsibility,» i.e., it can request that 
either the source LU or the target LU take 
responsibility for any session deactivations 


required as a consequence of a particular : 


verb issuance. Session limit decreases might 


leave the current session count in excess of \— 


the new limits. In this case, the LU with 
session-deactivation responsibility computes 


a termination count, which is the number of 
sessions it must deactivate to reach the new 
limits. Each LU has its own termination 
count, 1.e.,» one LU could be responsible for 
deactivating sessions to one Limit, but 
before it had done so, a subsequent verb 
could make the partner LU responsible for 
deactivating sessions from that limit to a 
newer limit. 


(LU,MODE ) ENTRY 


The LU maintains an (LU,mode) entry for each 
defined combination of partner LU and mode 
name. This describes the dynamic relative 
state of the local and partner LU for that 
mode name. This includes the session limits, 
session counts, drain state, and termination 
count. 


DISTRIBUTED OPERATOR CONTROL 


Change number of sessions (CNOS) is a 
control-operator distributed function to reg- 
ulate the number of parallel sessions between 
a pair of LUs and to determine when sessions 
will be activated or deactivated. A CNOS 
verb issuance causes the source LU to negoti- 
ate with the target LU to establish a mutual- 
ly acceptable number of parallel sessions. 


To do this, the control-operator transaction 
program at the source LU initiates a distrib- 


LOCAL FUNCTIONS AND SERVICES 


r 


Local control-operator verbs update 
definitional and operational parameters at 
the local LU without the participation of the 
operator at the remote LU. 


LU DEFINITION VERBS 


LU definition verbs are local 
control-operator verbs that define or display 
the locally-Known characteristics of the 
local LU and of network resources it 
accesses. These resources and the principal 
characteristics that can be defined or dis- 
played are: 


e Local LU: the fully-qualified LU name 
and the optional capabilities the LU sup- 
ports such as parallel sessions and map 
names 


e Partner LUs: the various names of poten- 
tial partner’ LUs: local LU name, 
fully-qualified LU name, and uninterpret- 
ed LU name; the optional capabilities of 
the partner LU such as parallel sessions; 
and the list of mode descriptions for 
that LU. 


uted transaction, using a conversation, with 
the target LU. It uses the conversation to 
send a copy of the operator command to the 
partner LU and to receive a reply from the 
partner. 


At the target LU, the transaction program 
that constitutes the partner for this trans- 
action is the CNOS service transaction pro- 
gram (CNOS' service TP), which’ issues 


complementary control-operator verbs to 
receive the command and send a negotiated 
reply. The negotiation uses an 


implementation-defined algorithm that does 
not depend on interaction with a human opera- 
tor, 1.e., 1t can run unattended, but it may 
use values supplied by that operator by ear- 
lier verb issuances, e.g., from LU definition 
verbs. The CNOS service TP may, however, use 
non-interactive implementation-defined means 
to inform the operator of any changes. 


Each program then changes its session limits 
and performs its local responsibility for 
deactivating sessions. 


The CNOS transaction requires use of a ses- 
sion. In order to allow operator commands to 
be exchanged regardless of the state of ses- 
sion traffic between the LUs, an SNA-defined 
mode name, SNASVCMG, is dedicated to sessions 
for the control-operator transactions. Each 
LU supports one session of each contention 
polarity for this mode name with each active 
partner LU. Thus,» an LU can always obtain a 
contention-winner session to send a CNOS com- 
mand to its partner. 


e Modes: the mode name and optional func- 
tions that are supported by a partner LU 
on a mode basis», such as sync point; and 
session parameters that characterize this 
mode, such as maximum RU size, pacing 
counts, and cryptography. 


e Transaction programs: the transaction 
program name, its availability, and the 
optional functions that it supports such 
as map names and sync point. 


The LU definition verbs consist of four 
DEFINE verbs (DEFINE_LOCAL_LU, 


DEFINE_REMOTE_LU; DEFINE_MODE , and 
DEFINE TP), four DISPLAY verbs’ (DIS- 
PLAY_LOCAL_LU, DISPLAY_REMOTE_LU, DIS- 


PLAY_MODE, and DISPLAY_TP), and one DELETE 
verb. See SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2 for detailed 


descriptions of these verbs. 
LOCAL SESSION-CONTROL VERBS 


Local session-control verbs are local 
control-operator verbs that set the session 
limits, contention polarity, and drain spec- 
ification for single-session mode names and 
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for mode name SNASVCMG, or that activate and 
deactivate single or parallel sessions for 
any mode name. 


The local session-control verbs are the fol- 
lowing. 


e INITIALIZE_SESSION_LIMIT sets the 
(LU,mode) session limit to allow one ses- 
sion, for a single-sessions mode name, or 
to allow one session of each contention 
polarity, for the parallel-session mode 
name SNASVCMG. This allows a session to 
be activated when requested by a trans- 
action program, or to be activated imme- 
diately (automatic activation) if so 
specified by a previously issued LU defi- 
nition verb. It also specifies the con- 
tention polarity to be selected when a 
session is activated by the local LU and 


DISTRIBUTED FUNCTIONS AND SERVICES 


CHANGE NUMBER OF SESSIONS VERBS 


Change number of sessions (CNOS ) 
control-operator verbs specify the maximum 
number of parallel sessions between two LUs, 
and, by implication, allow or require ses- 
sions to be activated or deactivated. The 
verbs also specify the minimum number of ses- 
sions allowed with each contention polarity. 
The verbs further specify whether the ses- 
Sions are to be activated or deactivated 
immediately or according to the needs of 
transaction programs, and which LU is respon- 
sible for activating or deactivating sessions 
to attain or maintain the number of sessions 
within the agreed limits. 


CNOS verbs are distributed- function 
control-operator verbs; they take effect only 
with the mutual participation of both the 
control operator at the source LU and the 
CNOS service transaction program at the tar- 
get LU, which enforces constraints previously 
specified by the control operator at that LU. 
The CNOS verbs are: 

e INITIALIZE SESSION_LIMIT 

e RESET_SESSION_LIMIT 

@ CHANGE_SESSION_LIMIT 


e PROCESS_SESSION_LIMIT 
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the contention-polarity negotiation rule 
to be used when a session is activated by 
a remote LU. 


e RESET_SESSION_LIMIT sets the (LU,mode) 
session limits to 0 to cause deactivation 
of any currently active sessions and to 
disallow any further session activations. 
It also specifies the drain mode, indi- 
cating whether sessions are to be deacti- 
vated immediately or only when there are 
no remaining requests for their use. 


e ACTIVATE_SESSION requests immediate acti- 
vation of a session. 


¢ DEACTIVATE_SESSION requests deactivation 
of a specific session. (This is the only 
control-operator verb that explicitly 
identifies a specific session. ) 


(The INITIALIZE _SESSION_LIMIT and 
RESET_SESSION_LIMIT verbs are included in 
both the local verbs and CN@S verbs. They 
are distinguished by the characteristics of 
their specified mode name..) 


CNOS verbs control the number of parallel 
sessions by 


limit; this limits the correspondine” ~ 
(LU,mode} session count. : 
A CNOS verb identifies the particular 


(LU,mode) entry that it affects, or it indi- 
cates that it affects all (LU,mode) entries 
for a given partner LU name. In the latter 
case, it affects all the (LU,mode) entries 
for the specified LU in the same way, e.g.> 
it applies the same drain specification and 
session-deactivation responsibility to all 
sessions. 


setting the (LU,mode) session _ 


a 
FUNCTIONAL RELATIONSHIPS FOR DISTRIBUTED VERB\_ 7 


PROCESSING 


The complete processing function for a CNOS 
verb issuance is distributed among several 
components at both the source and the target 
LUs. Figure 5.4-2 on page 5.4-7 illustrates 
the relationships among the major LU compo- 
nents involved in processing a CNOS verb. 
Different components are active at the source 
and target LUs; only the components active 
for the LU's role are shown for that LU. 
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5.4-2. LU Component Relationships for Distributed Session-Control Verbs 


OPERATION PHASES 


When the LU control operator invokes a CNOS 
function, the source and target LUs perform 
the following functions, in four phases. 


1. Operator Phase--Control-Operator Trans- 
action Program 


At the source-LU, the control-operator 
transaction program receives a CNOS 
request from the LU control operator (in 
an implementation-defined way) and» on 
behalf of the LU control operator, issues 
a CNOS verb. The appropriate CNOS verb 


invokes PS.COPR; this begins the next 
phase. 


Further details appear in 
"Control-Operator Transaction Program" on 
page 5.4-22. 


Negotiation Phase--PS.COPR 


PS.COPR at the source LU initiates a con- 
versation with PS.COPR at the target LU, 
via the CNOS service transaction program 
at the target LU. Using the conversa- 
tion, the source LU sends a change number 
of sessions GDS variable (CNOS command) 
carrying an encoding of the parameters 
that were specified in the  CNOS 
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control-operator verb. The target LU 
receives the CNOS command, negotiates 
acceptable session limits, drain specifi- 
cation, and session-deactivation respon- 
sibility, and sends the acceptable values 
of the parameters back to the source LU 
in another change number of sessions GDS 
variable (CNOS reply). 


The two LUs then terminate their conver- 
sation and make the agreed-upon changes 
to their respective (LU,mode) entries. 
Each LU then determines whether it is 
responsible for changing the session 


count, and if so, notifies its resources 


manager that the limits have _ been 
changed. 


This phase is’ performed synchronously 
with the transaction program issuing the 
CNOS verb, 1.e., it completes prior to 
return of control to the control-operator 
transaction program. Further details 
appear in “Session-Limit Services at the 
Source LU" on page 5.4-25 , "CNOS Service 
Transaction Program" on page 5.4-22, and 
"Session-Limit Services at the Target LU" 
on page 5.4-28. 


Action Phase--Resources Manager 


The resources manager (RM) at each LU 
receives the session-limits-change 
notification (CHANGE_SESSIONS ) from 
PS.COPR. RM determines whether any ses- 
sion activations or additional deacti- 
vations are required to bring the session 
count within the new session limits. If 
so, it performs the necessary session 
shutdown and issues requests for session 
deactivation to the session manager (SM). 
For example: 


e If the current session count is less 
than the minimum contention-winner 
limit and is also less’ than the 
automatic-activation limit, RM 
requests activations to reach the 
lower of these limits. 


e If the (LU,mode) session limit is 
decreased and the current session 
count is between the previous limit 
and the new limit, RM shuts down and 
requests deactivation of the number 
of sessions necessary to reduce the 
session count from the present value 
to the new limit. 


e If the (LU,mode) session limit was 
decreased but the current = session 
count is above the previous limit, RM 
requests the additional deactivations 
necessary to reduce the session count 
from the previous limit to the new 
limit (the RM with 
session-deactivation responsibility 
for the previous limit continues to 
request the deactivations that are 
necessary to reach that limit). 


e If the session count for either con- 
tention polarity encroaches on the 
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minimum contention-winner limit for 
the opposite polarity, RM requests 
deactivations sufficient to allow the 
minimum of each polarity, even if 
this would reduce the (LU,mode) ses- 
sion count below the (LU,mode) limit. 


When RM determines that some sessions 
must be deactivated, it might be that a 
sufficient number of sessions are not 
immediately free. So, each RM maintains 
a count, the termination count, of the 
number of sessions for which it has 
session-deactivation responsibility. It 
increments this count whenever a limits 
change requires the LU to deactivate 
additional sessions. It decrements this 
count when it requests a session deacti- 
vation. 


If the termination count is not 0, and 
the mutually-accepted drain specification 
so indicates, RM performs drain action, 
1.e., it continues to initiate conversa- 
tions until no requests for new conversa- 
tions for the specified LU name and mode 
name are pending from any transaction 
program. | 


When drain action is completed, or if it 
was not requested, RM selects sessions of 
appropriate contention-polarity to be 
deactivated. It then shuts down all 
traffic on each selected session: after 


each partner LU ends its last bracket, 2 aioe 


sends the BIS RU; when the partner 
receives this, it Knows that there are no 
more brackets in transit from its part- 
ner. RM then issues requests to the ses- 
sion manager to deactivate the selected 
sessions. 


This phase is performed asynchronously 
with the transaction program issuing the 
CNOS verb. (Details of these functions 
are discussed in Chapter 3. ) 


Enforcement Phase--Session Manager 


Whenever the session manager (SM) 
receives a request to activate a session 
from RM or from the remote LU (via the 
PU), 1% checks the current session counts 
and session limits to determine whether 
another session of that contention polar- 
ity is allowed. (The resources manager 
also assists in limits enforcement by 
checking the current counts and limits 
before issuing session activation 
requests. ) If another session 1S 
allowed, SM issues the appropriate BIND 
or response to BIND; otherwise, it 
rejects the request. 


Whenever the session manager receives a 
request to deactivate a session, it 
issues UNBIND or response to UNBIND. 


This phase is performed asynchronously 
with the transaction program issuing the 
CNOS verb and after the action phase. 
(For details of this phase, see Chapter 
4.) 
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The figure shows the verbs issued and their most significant parameters. 
Numbers in the left column refer to the explanation in the text. 
Arrows represent information exchange resulting from verbs issued by the two transaction 


programs. 
5.4-10. ) 


(For an explanation of the actual message units exchanged, see Figure 5.4-4 on page 


Figure 5.4-3. Sequence of Verbs and Information Exchange in CNOS Transaction Programs 


( 


CNOS TRANSACTION 


The control-operator transaction program and 
the CNOS service transaction program, togeth- 
er with their corresponding PS.COPR compo- 
nents, process a distributed transaction to 
exchange the CNOS command and reply. The 
sequence of basic conversation verbs issued 
by PS.COPR at the source and target LUs is 
shown in \Figure 5.4-3. The following com- 
ments correspond to the numbered steps in 
that figure. | 


1. The control-operator transaction program 
at the source LU issues one of the 
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control-operator verbs INITIAL- 
IZE_SESSION_LIMIT, CHANGE_SESSION_LIMIT> 
or RESET_SESSION_LIMIT. This activates 
PS.COPR at the source LU (source-LU 
session-limit services > abbreviated 
SSLS). SSLS builds the CNOS command and 
issues a sequence of conversation verbs. 


The source LU issues ALLOCATE to initiate 
a conversation with the target LU and to 
build an Attach FM header to invoke the 
CNOS service transaction program (having 
TP name X'O6F1'). When the target LU 
receives the Attach, it initiates the 
CNOS service transaction program. 
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3. The CNOS service TP issues the PROC- When the reply arrives at the source LU, 
ESS SESSION_LIMIT verb. This activates the RECEIVE_AND_WAIT verb. previously 
PS.COPR at the target LU (target-LU issued by SSLS completes, and SSLS 
session-limit services, abbreviated receives the reply. 

TSLS), which issues a sequence of conver- 

sation verbs complementary to those being 11. TSLS issues DEALLOCATE to end the conver- 

issued at the source LU. sation. This sends an indication to the 
source LU that the conversation is ended. 

4. The source LU issues GET_ATTRIBUTES and | ee i 
GET_TP_PROPERTIES to get the partner's LU. Meanwhile, SSLS issues RECEIVE _AND_WAIT 
name and its own LU name to resolve races to receive the deallocation notification. 
between contending CNOS commands. 

12. SSLS issues DEALLOCATE to complete its 

5. TSLS issues the GET_TYPE verb to verify processing of the conversation. 
that this is a basic conversation. 

13. Now both SSLS and TSLS have a copy of the 

6. TSLS issues the GET_ATTRIBUTES verb to negotiated reply record containing the 
verify that the attributes of the conver- agreed-upon limits, drain specification, 
sation are those expected, and to get the and deactivation responsibility. They 
partner LU name. The latter is used to each update the session limits in their 
resolve races between contending CNOS local data structures and inform the 
commands. resources manager. 

7. SSLS issues SEND DATA to send the CNOS 14. When SSLS and TSLS have finished process- 
command to TSLS. : ing the CNOS reply, they return control 

to their respective callers, the trans- 
Meanwhile, TSLS issues RECEIVE_AND_WAIT action programs that issued the CNOS 
to receive the command. verbs. These transaction programs’ then 
perform any further 

8. SSLS issues RECEIVE_AND_WAIT to receive implementation-defined actions, such as 
the reply from SSLS. This verb has the notifying the LU operators of the change. 
added effect of sending a | 
Change-Direction indication to TSLS» giv- If, during the conversation, either LU 
ing TSLS permission to send. | detects a message unit or return code that 

does not conform to this protocol, 1t termi- 
Mearwhile, TSLS issues RECEIVE_AND_WAIT nates the conversation by issuing DEALLOCATE 
to receive the Change-Direction indi- TYPE(ABEND) (not shown in Figure 5.4-3), and 
cation. the partner responds with DEALLOCATE 
TYPE( LOCAL ). 

9. TSLS negotiates the proposed session lim- 

it parameters and builds the CNOS reply. For further information .on verb usage, see 
SNA Transaction Programmer's Reference Manual 

10. TSLS issues SEND DATA to send the reply for LU Type 6.2. 
to SSLS. 

Source LU Target LU 

Hal f—Session Hal f—Session 

o re) 

.*BB, RQE1, CD, FMH-5(Attach TPN=X'06F1'), GDSID=X'1210', command data . 

© ea a a a aa © | 

; RQE1, CEB, GDSID=X'1210', reply data 4 

o< fe) 


Notes: 


Each arrow represents a chain, which comprises one or more request units. 
FMH-5( Attach TPN=X'O6F1') is the encoding of the Attach from the ALLOCATE verbs. 
Request-header indication CD is the encoding of Change Direction. 


Request-header indication CEB is the encoding of Deallocate-normal. 


@ 
® 
° 
e GDS ID=X'1210' distinguishes the CNOS command or reply record from other GDS variables. 
e 
e 


These flows are generated by the CNOS transaction as illustrated in Figure 5.4-3 on page 5.4-9. 
Unless errors occur, the CNOS transaction always generates the same flow. 


Figure 5.4-4. 


5.4-10 


SNA LU 6.2 Reference: 


CNOS External Message-Unit Flows 
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c. “, 


ar 
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CNOS EXTERNAL MESSAGE-UNIT FLOWS 


The CNOS' transaction presented in  "CNOS 
Transaction" on page 5.4-9 causes other LU 
components to generate the request chains 
shown in Figure 5.4-4 on page 5.4-10. This 
is the external representation of the infor- 
mation exchanged by the verbs. 


Exactly one bracket is initiated for each 


CNOS verb. issued at the source LU. The 
bracket consists of exactly two chains, each 


PS.INITIALIZE 


CNOS 
Service 
Transaction 
Program 

x'O6F1' 


Target—LU 
Session— [SLDLM.... cece ccccsccece > (LU, < 
Limit ° | mode) | 
Services 
PS.COPR 


PS .CONV 
A 
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® Transaction Program 


® Process 
©0000000006 e@e0000080080080 


e 
e 
e 
e 
e 
e 
e 
e 
e 
e 
e 
e 
e 
e 
e 


containing exactly one Change Number Of Ses- 


sions GDS variable (CNOS command or CNOS 
reply). 


A single CNOS verb generates only one chain 
in each direction, even if MODE_NAME(ALL) is 
specified. In that case, the verb affects 
all mode names the same, e.g., there is a 
single negotiated response» and all (new) 
session deactivations have the same drain 
status and session-deactivation responsibil- 
ity. 


PS .INITIALIZE 


Control—Operator 
Transaction 
Program 


@ 
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(to target LU) 


juxtaposed boxes: Call/return relationship (within a process) 


< > Send/receive relationship (between processes ) 
ee or > Access to shared data 
eeeeee Process boundaries 


<smmm™> = Transaction program interaction (with transaction programs at other LUs) 


SLDLM session—-limit—data-—lock manager 
Note: Verb routers have been omitted. 


Figure 5.4-5. CNOS Process Interactions at a Single LU 


THE CNOS PROCESS RELATIONSHIPS 


Processes 


The LU components that support the CNOS func- 
tion are distributed among several processes, 
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as illustrated in Figure 5.4-5. 


The source transaction-program process con- 
tains the control-operator transaction pro- 


gram; this program interacts with the 
internal LU components by issuing 
control-operator verbs, specifically, INI- 


TIALIZE_SESSION_LIMIT, CHANGE_SESSION_LIMIT, 
and RESET_SESSION_LIMIT. ; 
The target transaction-program process con- 
tains the CNOS service transaction program. 
This program interacts with the internal LU 
components by issuing the. PROC- 
ESS _SESSION_LIMIT verb. 


(The transaction programs also interact with 
the LU control operators in an 
implementation-defined way. ) 


Each transaction-program process also con- 
tains within PS.COPR a session-limit services 
component (source or target), which processes 
the control-operator verbs. In processing a 
CNOS control-operator verb, session-limit 
services interacts with other LU components 
and, indirectly, with its peer in the partner 
LU, by issuing basic conversation verbs, 
e.g.» ALLOCATE, SEND_DATA, RECEIVE_AND_WAIT, 
and DEALLOCATE. Session-limit services also 
accesses the (LU,mode) entries within the 
internal environment of the LU. 


Multiple CNOS transaction-program processes, 
and corresponding half-session processes, can 
be active concurrently at any LU. For exam- 
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ple, both the local control operator and a 
remote control operator might issue a CNOS 
verb at about the same time... Or two remote 
operators might both issue CNOS to the same 
LU. The local LU implementation might even 
allow two control-operator transaction pro- 
grams to be active at the same time. 


(Only one instance of the resources-manager 
process exists per LU.) 


Shared Data 


An (LU,mode) entry is a shared data structure 
owned by the LU process (not shown). An 
(LU,mode) entry exists for each combination 
of mode name and potential partner LU. Each 
(LU,mode) entry contains the session limits 
and other CNOS parameters affected by the 
CNOS verbs, such as the drain status. (It 
also contains other fields not used by CNOS. ) 


Each (LU,mode) entry also is associated with 


a session-limit-data lock field, that serves 
as a lock on that entry to prevent simultane- 
ous changes to the entry by different 
control-operator verb issuances. The state 
of the session-limit-data lock is maintained 


by the session-limit-data-lock manager 
(SLDLM), a PS.COPR component that = each 


transaction-program process invokes to obtain 
or release exclusive use of an (LU,mode) 
entry. 
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Transaction-Handling Process Relationships 


Single Verb Issuance: 


A single issuance of a 
CNOS verb uses unique instances of a 
control-operator transaction program process 
and half-session process at the source LU and 
of a CNOS service-transaction program proc- 
esses and half-session process at the target 
LU. These processes have shared access to 
the single instances of the resources manager 
process and the set of (LU,mode) entries at 
their respective LUs. These components, with 
the conversation between them, process a sin- 
gle CNOS transaction, as illustrated in Fig- 
ure 5.4-6 on page 5.4-12. 


Several different cases of process and trans- 
action relationships can occur when two CNOS 
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verbs are issued concurrently at a local LU, 
at two partner LUs, or at both a local and a 
partner LU. If the two verb issuances are 
not contending for the same (LU,mode) entry, 
both verb issuances complete concurrently (if 
no errors occur). But if the two verb issu- 
ances are contending for the same (LU,mode) 
entry, one of the issuances will fail. 


To determine whether two transactions are 
contending for the same (LU,mode) entry, and 
if so, which one wins the contention, each 
transaction-program process invokes its 
session-limit-data-lock manager. Details of 


this contention detection and resolution are 
described in "CNOS Race Resolution" on page 
5.4-14. 
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Figure 5.4-7. 
Partner LUs 


Transaction program interaction (between LUs) 


Simultaneous Verb Issuances at Partner LUs: 


verb from both the local LU and from the 


partner LU, for either 


(LU,mode) entries, 


both the source 


the same or different 
and the 


target processes are active at each LU, as 


illustrated 


in Figure 5.4-7 on page 5.4-13. 


Simultaneous Verb Issuances at the Same LU: 


transaction 
active, 
concurrently 


programs 


at that 
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to be concurrently | 


then if two CNOS verbs are issued 


LU, two  source-LU 
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Transaction Handling Component Relationships--Case 2: 


transaction-program processes become active 
in Figure 5.4-8. 
the process handling 


at that LU, 


If contention results, 
the later verb issuance will terminate with- 
out initiating a conversation with its part- 
If no contention results, 
processes and transactions are active at the 
This case is not illustrated, but 
is similar to Figure 5.4-7 on page 5.4-13, 
roles of source-LU and target-LU 


ner. 
local LU. 


with the 


as illustrated 


appropriately reversed. 
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two source 
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1. The CNOS source transaction-program process attempts to lock an (LU,mode) entry after another 


source transaction-program had locked it but had not yet unlocked it. 


The later process is 


denied the lock and recognizes the contention; it goes away. 
2. <A target transaction-program process corresponding to the failing source process is never 


activated. 


Figure 5.4-8. 
the Same LU 


CNOS RACE RESOLUTION 
Command Race 


Two LU control operators might simultaneously 
issue a CNOS verb affecting the same LU name 
and mode name. If such a verb is issued 
while another such verb at either the source 
or the target LU is in the negotiation 
phase, i.e.» a prior instance of PS.COPR is 
active on either LU for the same (LU,mode) 
entry or entries», a command race _ has 
occurred, and one (but not both) of the verbs 
fails. 


If a verb‘is issued when a previous verb is 
in the action phase, i.e., PS.COPR has 
already updated the (LU,mode) entry, but the 
resources manager and the session manager 
have not yet completed adjustments to the 
session count, an action race has occurred 
and neither verb fails. For details, see SNA 
Transaction Programmer's Reference Manual for 


LU Type 6.2 and Chapter 3 of this volume. 
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Transaction Handling Component Relationships--Case 3: 
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Simultaneous Verb Issuances at 


Locking the (LU,mode) Entry 


When a command race occurs, PS.COPR assures 
that exactly one of the commands completes 
successfully by observing a locking protocol 
for the (LU,mode) entry. The session-limit 
services routines invoKe a_ shared component, 
session-limit-data-lock manager (SLDLM), to 
prevent simultaneous access to an (LU,mode) 


entry, to detect races, and to resolve 
double-failure race conditions. 
Source-LU session-limit services (SSLS) of 


PS.COPR tests and simultaneously sets the 
CNOS lock in the (LU,mode) entry by issuing 
LOCK to its SLDLM before allocating a conver- 
sation to the target LU. If another instance 
of session-limit services has already locked 
the (LU,mode) entry» SSLS returns an error 
code. It does not send the CNOS command to 
the target LU or modify the session-limit 
parameters in the (LU,mode) entry. 


If SSLS succeeds, target-LU session-limit 
services (TSLS) at the partner LU issues LOCK 
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to its SLDLM after receiving the CNOS command 
from the source LU. If TSLS finds the lock 
at its LU already set (for example, because a 
control-operator transaction program at its 
LU, acting as source LU, had simultaneously 
issued a CNOS verb), then TSLS sends the 
partner LU a CNOS reply with a reply-modifier 


value indicating that a command race was 
detected. It does not modi fy the 
session-limit parameters in the (LU,mode) 


entry. 


In some cases, two commands issued simultane- 
ously from each LU could both be rejected. 
For example, each LU might issue its command 
before the other’ arrived. Each target 
session-limit services would then reject the 
command from the partner because its source 


session-limit services had a command out- 
standing. This is called a double-failure 
race condition. To detect this case, SLDLM 
maintains another indicator, LOCK_DENIED. 
This is set by TSLS when it sends a 


command-race-detected reply modifier. 


When SSLS receives the reply from TSLS, it 
checks the reply to determine whether the 
partner LU rejected the command because it 
detected a race. If so, it also tests the 
session-limit-data lock to determine if; 
meanwhile, its LU, acting as a target LU for 
another CNOS command, has rejected a command 
from the partner LU. SLDLM determines this 
from the LOCK_DENIED indicator. 
(LOCK_DENIED, together with the receipt of a 
command-race-detected reply modifier, indi- 
cates a double-failure race condition; 
either LOCK_DENIED or command-race-detected 
alone does not represent a double failure. } 


Race Flows 


Example flows for the types of command races 
that can occur are shown in Figure 5.4-10 on 
page 5.4-17, Figure 5.4-11 on page 5.4-18, 
and Figure 5.4-12 on page 5.4-19. The flows 
for the no-race case are shown in Fig- 
ure 5.4-9 for comparison. 
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In the figures: 


The 


The change number of sessions commands 
sent from each of the two LUs are on dif- 
ferent conversations. 


The columns labeled "Transaction-x" show 
the actions performed by the CNOS 
transaction-program processes in process- 


6 


ing a CNOS verb issued by the control — 


operator at LUa. 


The columns labeled “Transaction-y" show 
the actions performed in processing a 
CNOS verb issued by the control operator 
at LUb. 


The column = labeled "(LU,mode) entry 
(LUb,m)" shows the changes made by the 
two transactions to the (LU,mode) entry 
for LUb, mode name m at LUa. 


The column labeled "(LU,mode) entry 
(LUa,m)" shows the changes in the corre- 
sponding (LU,mode) entry for LUa, mode 
name m at LUb. 


MAX_SESS represents the session limit for. 


mode name m in the (LU,mode) entry. 


SLD_LOCK represents the state 
UNLOCKED» DENIED ) of 
session-limit-data lock. 


(LOCKED > 
the 


flows shown are: 


\ 


A CHANGE_SESSION_LIMIT verb (abbreviated 


CHANGE_SESSLIM) 


The CNOS commands and replies exchanged 
by the CNOS' transaction-program proc- 
esses » . 


The internal requests (LOCK, TEST; 
UNLOCK) and their replies (OK, REJECT; 
DENIED ) es 

Update actions on the (LU,mode ) 
session-limit field of the (LU,mode) 
entry 


yo 
a 


Transaction-x 
source process 


LUa 


(LU,mode) | Transaction-y 


target process 


entry 
( LUb om) 


(MAX_SESS is n3 
SDL_LOCK is UNLOCKED) 
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LOCK ‘ 
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(SDL_LOCK is UNLOCKED) 


Transaction-y 
source process 


.CNOS reply (MODE(m),0OK) 


LUb 


Transaction-x 
target process 


(LU,mode) 


entry 
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Numbers in the left column refer to explanations in the text. 


5.4-9. No Race: 


No Race: If only one LU issues a CNOS com- 
mand, no race occurs, and the transaction is 
successful. 


Figure 5.4-9 on page 5.4-16 shows the no-race 


case. In this example: 

1. Before sending the CNOS command, the 
source LU (LUb) attempts to lock the 
affected (LU,mode) entry. 

2. Since no other CNOS transaction at LUb 
has the (LU,mode) entry locked, the 
attempt is successful. 

3. LUb now issues the CNOS command. 

4. When the target LU (LUa) receives the 
CNOS command, it attempts to lock the 
(LU,mode) entry. 

5. Since no other CNOS transaction at LUa 
has the (LU,mode} entry locked, the 


attempt is successful. 


6. LUa then negotiates and sends the CNOS 
reply. 


7. LUa then updates the (LU,mode entry). 


Similarly, when LUb receives the reply, 
it also updates its (LU,mode) entry. 
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Only One LU Issues a CNOS Verb 


8. Both LUs unlock the 
The 
for updating by subsequent CNOS verbs. 


Single-Failure Races: 
cases 
page 5.4-18), 


the (LU,mode) entry. 


eters. 
single-failure 


Figure 5.4-10 shows a 


action for a verb issued at the other LU. 
this example, 


1. (LUa's 
not busy when the command arrived. 


2. LUb's 


mand arrives, 
processing has completed at LUb. 


3. When LUb receives the REJECT reply, 


tests for LOCK_DENIED, which is not set, 
and so determines that no command from 
(for mode name m) has been rejected 


LUa 


(LU,mode) entries. 
(LU,mode) entries are now available 


In the single-failure 
(Figure 5.4-10 and Figure 5.4-11 on 
one transaction fails; it does 
not modify the session-limit parameters in 
The other transaction 
succeeds and changes the session-limit param- 


race 
condition in which one transaction's command 
and reply both cross the reply of the trans- 


command succeeds because LUb was 


command fails because LUa's verb 
has not completed at LUa when LUb's com- 
even though LUa's verb 
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Transaction—-x 
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process 


CNOS reply (MODE(m) OK). 


(MAX_SESS 


(SDL_LOCK 
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.update (MAX_SESS(i)) 
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‘ UNLOCK 


1s UNLOCKED) 


CHANGE_SESSLIM(LU(LUa) MODE(m) MAX_SESS(3)) 


LOCK 


Oevreccevrevsecvee 


Oo 


(SDL_LOCK 
OK 


.CNOS reply (MODE(M) RACE_REJECT) 


> 
1s LOCKED) 


is 1 [no change]) 


: (MAX_SESS 
; TEST 

On 5 oe oh 0S a ee es > 

; OK : 

re ee ee eee ee Oo 

: UNLOCK ; 

Oss 686 eS Se ees > 

: (SDL_LOCK is UNLOCKED) 


Numbers in the left column refer to explanations in the text. 
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and therefore does not attempt to retry 
the command. 


Figure 5.4-11 shows another’ single-failure 


race condition, in which one transaction's 
command and reply cross the command of the 
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Command Crosses Reply 


transaction for a verb issued at the other 
In this example, 


LU. 


a 


LUb's command fails because LUa's command 


has not completed when LUb's 


arrives. 


command 


Cc 


LUa 


tests LOCK_DENIED and determines that no 
command from LUa (for mode name m) has 
been rejected and therefore it does not 
attempt to retry the command. 
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LUb 


Transaction-x (LU,mode) | Transaction-y Transaction-y (LU,mode) | Transaction—x 
source process entry target process source process entry target process 
‘ (LUb m) F ; (LUa,m) 
‘ (MAX_SESS 1s n; ‘ (MAX_SESS is n35 
‘ SDL_LOCK is UNLOCKED) ‘ SDL_LOCK is UNLOCKED) 
CHANGE_SESSLIM( LU(LUb) MODE(m) MAX_SESS(1)) 
‘ LOCK ‘ j 
Dasosoee i Mates > ° 
(SDL. LOCK is LOCKED) ; CHANGE _SESSLIM(LU(LUa ) MODE(m} MAX -SESS(5)) 
P OK $ - : LOCK ‘ 
See ee ee ee oO On cenecccccneccs > 
-CNOS command (MODE(m) MAX_ SESS(i)) (SDL_LOCK is LOCKED) 
‘ OK ‘ 
: . Tre ert ee ee Oo 
i é -CNOS command (MODE(m) MAX_SESS(j)). 
foo ; : ————_—___—_——————o 
= ; LOCK 
7 SS etgiatatiore decal Ss ae oO 
(SDL_LOCK is DENIED) 
‘ REJECT A 
Ons 66 sew ak eta > 
(MAX_SESS is n [no change]) 
1 ‘ -CNOS reply (MODE (im) RACE_REJECT ) 
o> 
(MAX_SESS is n [no change) 
2 
C 
3 : ? CNOS reply (MODE(m) OK). 
fo . 2 
= .update (MAX_SESS(i)) .UPDATE (MAX_SESS(i)) 
““ 2 ee ae ere ee ee > So 
(MAX_SESS is 1). (MAX_SESS is 1) 
: UNLOCK i P ‘ UNLOCK ‘ 
Pere er a eee ee > ° Se ee re) 
(SDL_LOCK is UNLOCKED) - (SDL_LOCK is UNLOCKED) 
NOTE: Numbers in left column refer to the explanations in the text. 
Figure 5.4-11. Single-Failure Race Condition--Case 2: Command and Reply Cross Command 
2. When LUb receives the REJECT reply, it 3. LUa's command succeeds because LUb's 


unsuccessful command has already com- 
pleted at LUb, and has released the lock, 
before LUa's command arrives at LUb. 
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6 aaa a aa | SSS a 

Transaction-x (LU,mode) | Transaction-y Transaction-y -(LU,mode} | Transaction-x 
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5 e 
C 
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8 : UNLOCK 
Deere ccccsceves > ° 
(SDL_LOCK is UNLOCKED) 
° ° ° ° ° —_ 

9 : -CNOS command (MODE(m) MAX_SESS(j3)). c 4 

Ce . . vague 
° LOCK . 
. Gee c ceases enens fe) 
(SDL_LOCK is LOCKED) . 
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fe} @eeeseeeseoesese#e¢es8#ees#¢@ > ° e 
-CNOS reply (MODE(m) OK) ; 
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.update (MAX_SESS(j)) .update (MAX_SESS(j)) : 
re fe) Decccevevevevece > . 
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: (SDL_LOCK 
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Figure 5.4-12. Double-Failure Race Condition: 


Double-Failure Race: 
case (Figure 5.4-12 on page 5.4-19), 
transactions initially fail. 
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In the double-failure 


The SSLS compo- 


(SDL_LOCK is UNLOCKED) 


Numbers in left column refer to explanations in the text. 


Command Crosses Command, Reply Crosses Reply 


nents at each LU disesver the double failure 


and compare their fully-qualified LU names to 
resolve it. (For the comparison, the 


both 


fully-qualified LU names are left-justified 
and padded to the right with space [X'40'] 
characters to make the lengths equal.) The 
LU with LU name lower in EBCDIC collating 
sequence loses; the verb fails as in a 
single-failure race condition. The LU with 
LU name higher in EBCDIC collating sequence 
retries the CNOS command, i1.e., 1t allocates 
a new conversation and sends the same CNOS 
command again. If no further errors occur; 
the verb eventually succeeds. 


Figure 5.4-12 on page  5.4-19 shows a 
double-failure case. In this example: 


1. Operators at both LUs’~= simultaneously 
issue CNOS verbs. 


2. The source processes successfully lock 
the (LU,mode) entries at their respective 
LUs, and issue CNOS commands. 


3. The commands cross in transit. 


G. When the commands arrive, the target 
processes attempt to lock the (LU,mode) 
entries but fail because they are already 
locked by the source processes of the 
other transaction, each of which has not 
yet received the reply to its own com- 
mand. The failing attempt to lock also 
sets the LOCK_DENIED state of the lock. 
MAX SESSIONS remains temporarily at n. 


5. Each target process sends a reply indi- 
cating a race reject. These replies also 
cross in transit. 


6. When the REJECT replies arrive, each 
source transaction program tests 
LOCK_DENIED and finds it set, indicating 
that a target transaction program at the 
same LU had attempted to set the lock but 
had been refused. This is a double fail- 
ure: the local LU's own command has 
failed, and meanwhile the local LU has 
rejected a command from the partner LU. 


BASE AND OPTIONAL SUPPORT 


The basic and optional functions available at 
the control-operator protocol boundary are 
defined in SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2. This section 
relates those functions to the capabilities 
of the components in the formal description. 


BASE -FUNCTION-SET SUPPORT 


All implementations support an 
implementation-de fined control-operator 
transaction program that is able to issue any 
of the required (base (function set) 
control-operator verbs and all optional 
control-operator verbs and parameters that 
the LU supports. 


7. Each source process compares LU names to 
determine whether it should retry. 


8. The LU with low LU name (LUa) releases 
the lock and terminates its CNOS verb to 
avoid another race. 


9. The LU with the high LU name (LUb) 
re-issues the command. Processing con- 
tinues as in the no-race case (Fig- 
ure 5.4-9 on page 5.4-16). 


RECOVERY FROM CONVERSATION FAILURE 


If conversation failure, e.g.» session out- 
age, were to occur during CNOS processing> 
the CNOS command would not complete success- 
fully at the source LU. Nevertheless, it 
might complete at the target LU, for example, 
because the reply was lost after the target 
LU had already deallocated the conversation. 
In this case, the session limits could become 
different at the two LUs. 


To prevent this discrepancy, SSLS retries any 
command that fails because of conversation 
failure. Since the original session has been 
lost, SSLS attempts to obtain a new session 
on the same or another mode name. It first 
tries to obtain a session with the mode name 
that failed, then with mode name SNASVCMG (if 
different), then with each mode name affected 
by the command, until either the command suc- 
ceeds or the LU determines that no session 
can be allocated with any affected mode name. 
Session limits can be reset even if the local 
LU is not able to contact or complete a con- 
versation with the partner’ LU. The 
FORCE(YES) parameter on RESET_SESSION_LIMIT 
instructs the control operator to set the 
local session limits to 0O even if the CNOS 
transaction 1s unable to complete successful- 
ly. This permits the LU to perform some 
clean-up that is not normally possible until 
session limits are 0 and no sessions are 
active. 


The base function set, supported by all 
implementations, includes the functions cor- 
responding to the LU definition verbs, 1.e., 
the ability to specify the values of certain 
LU parameters that are chosen by the instal- 
lation. An implementation may support issu- 
ing these verbs from the control-operator 
transaction program. Alternatively, instead 
of exposing these verbs at the 
control-operator protocol boundary, the 
implementation may provide other support in 
the form of installation-time, IPL-time, or 
run-time processing of the system-definition 


values, as long as the values are initialized 


prior to first use. 


The base function set also includes local 
support of the functions of INITIAL- 
IZE_SESSION_LIMIT and  RESET_SESSION_LIMIT 
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that apply to single-session mode names, and 
includes receive support for remotely-issued 
ACTIVATE_SESSION and DEACTIVATE_SESSION 
verbs. 


All LUs providing an “open" protocol bounda- 
ry> i.e.» one to which application trans- 
action programs have access, also support 
parallel sessions, including the CNOS minimum 
support (see "CNOS Minimum Support Set" on 
page 5.4-21). 


Parallel-session LUs optionally = support 
optional function set parameters of the CNOS 
verbs (see "Parallel-Session Optional Func- 
tions" on page 5.4-21). 


LUs with a “closed" protocol boundary, i1.e.; 
one to which application transaction programs 
do not have access, may optionally support 
parallel sessions and the corresponding CNOS 
minimum support. 


CNOS MINIMUM SUPPORT SET 


The CNOS minimum-support functions are: 


° Send (source) support for  INITIAL- 


IZE_ SESSION_LIMIT 
This increases the session limit from 0. 
e Send support for RESET_SESSION_LIMIT 


This resets the session limit to 0. This 
does not allow the local LU to initiate 
new conversations after the verb com- 
pletes, but it allows the LU to accept 
new conversations initiated by a partner 
LU. 


e Receive (target) support for all CNOS 
verbs, except that: 


- The target LU may unconditionally 
change RESPONSIBLE( TARGET) to RESPON- 
SIBLE( SOURCE }. 


- The target LU may unconditionally 
change DRAIN_TARGET( YES) to 
DRAIN_TARGET(NO}). 

The minimum-support CNOS components are: 
e An implementation-supplied 


control-operator transaction program that 
can issue the CNOS minimum-support verbs 


e The CNOS' service transaction program 
(TPN=X'O6F1° ) 

e Presentation services for the _ control 
operator (PS.COPR), except for the 
optional functions listed in 
"“Parallel-Session Optional Functions" on 
page 5.4-21 

¢ Support for a sufficient number of 


reserved sessions using the SNA-defined 
mode name SNASVCMG 
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The LU provides the capability for two 
such sessions for each LU with which’ the 
LU can have concurrently-active parallel 
sessions; these mode-name-SNASVCMG ses- 
sions are in addition to the sessions 
provided for user transactions. For each 
potential parallel-session partner LU, 
the operator specifies an (LU,mode) entry 
with mode name SNASVCMG and with limits 
allowing one contention-winner and one 
contention-loser session. 


(The SNA-defined mode name is provided so 
that PS.COPR will always be able to acti- 
vate a session to send the CNOS command, 
even when all other session limits are 
0, as in the initial state, or when all 
other active sessions are in in-brackets 
state or are bidder sessions on which a 
bid request is being refused. ) 


An LU that provides only the  CNOS 
minimum-support does not expose 
MIN_CONWINNERS_TARGET,» RESPONSIBLE >» or 


DRAIN_TARGET at the control-operator protocol 
boundary. In that case, the source LU sends 
MIN_CONWINNERS_TARGET( implementation choice), 
RESPONSIBLE(SOURCE), and DRAIN_TARGET( YES) 
for those parameters that it does not expose. 


PARALLEL-SESSION OPTIONAL FUNCTIONS 


The optional parallel-session CNOS functions 
are: 


e Receive support for DRAIN_TARGET( YES) 


This means that the LU supports local 
drain, i.e.» it is able to start new con- 
versations after the session limit is 
reset to 0 and to defer deactivating ses- 
sions until there are no =*more_ local 
requests for new conversations. 


e Send support for any or all of the fol- 
lowing: 


= MIN_CONWINNERS_TARGET 


RESPONSIBLE ( TARGET } 
a DRAIN_TARGET(NO ) 


This means that the LU exposes these 
parameters at the control-operator proto- 
col boundary. 


® Receive support for RESPONSIBLE( TARGET ) 


This means the LU can be responsible for 
decreasing the session count to a nonzero 
value, 1.e., it maintains an exact count 
of sessions to be terminated. 


e Send support for CHANGE_SESSION_LIMIT 
This means that the LU can increase or 


decrease the session limit to a nonzero 
value when it is currently nonzero. 
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This section describes the functions and 
interrelationships of the components for 
control-operator functions. 


The principal components are: 


e Presentation services for the control 
operator (PS.COPR) 


e Control-operator transaction program 
e CNOS service transaction program 


To perform its functions, PS.COPR may invoke 
the following other LU components: 


e Resources manager (RM), which performs 
session shutdown and invokes the session 
manager for session initi- 
ation/termination and acti- 
vation/deactivation 


e Presentation services for conversations,» 
which uses an LU-LU half-session for the 
conversation with the partner LU 

Figure 5.4-1 on page 5.4-2 illustrates the 

relationships among these components. 

TRANSACTION PROGRAMS 


Control-Operator Transaction Program 


The control-operator transaction program is 
an implementation-defined transaction pro- 
gram at the source LU that represents the LU 


control operator. It forms part of the 
local-LU (source-LU) transaction-program 
process. It is invoked by _ presentation 


services (PS.INITIALIZE) as a result of an 
implementation-def ined program-initiation 
request. 


The control-operator transaction program may 
interact with a human operator, at the imple- 


mentation- and/or installation-option, to 
obtain input parameters or to present 
results. It issues any of the supported 


control-operator verbs exposed at the 
control-operator protocol boundary. 


The transaction program passes to PS.COPR a 
transaction-program-verb structure specifying 
the verb type and verb parameters. When 
PS.COPR processing is complete, the trans- 
action program is returned the same structure 
containing the returned parameter values, 
e.g.» a return code indicating success or a 
failure reason. 


CNOS Service Transaction Program 


The CNOS service transaction program is that 
SNA-de fined transaction program with 


transaction-program name (TPN) X'O6F1'. It 
represents the control operator at the target 
LU. It is invoked by presentation services 
(PS.INITIALIZE) when the target LU receives 
the Attach FM header that resulted from the 
ALLOCATE verb issued by PS.COPR at the source 
LU. 


The CNOS service transaction program performs 
the following functions. 


e It is the target for the ALLOCATE verb 
issued by the source-LU control-operator 
transaction program. By being invoked, 
it completes the activation of the con- 
versation for the CNOS’~ transaction. 
(The characteristics of the conversation 
are discussed in section "CNOS Conversa- 
tion Allocation" on page 5.4-27. The 
conversation parameters from the Attach 
FM header are verified by the resources 
manager and presentation services’ for 
conversations before this program is 
invoked. ) 


e It issues the PROCESS SESSION LIMIT verb 
before any other processing. Thus, the 
CNOS service transaction program does not 
Induce any undue delay» e.g., it does 
not wait on operator input. It also does 
not affect the values of the negotiable 
parameters; these values are determined 
by an algorithm within PS.COPR. 


The CNOS' service transaction program 
passes to PS.COPR a 
transaction-program-verb data structure 
specifying the verb type and identifying 
the return parameters for the CNOS verb. 
When PS.COPR processing is complete, the 
CNOS service transaction program is 
returned the same structure containing a 
return code indicating success or a fail- 
ure reason and other parameters identify- 
ing the (LU,mode) entry or entries 
affected by the CNOS command. The PROC- 
ESS _SESSION_LIMIT verb does not provide 
the values of the session-limit parame- 
ters to the CNOS service transaction pro- 
gram; these values are available by 
issuing the DISPLAY verb. 


When control returns from the PROC- 
ESS SESSION_LIMIT verb, the conversation 
with the source LY has already been deal- 
located and the session-limit parameters 
have been updated at the target LU. 


e It performs an implementation-defined 
action to notify its control operator of 
the activity. For example, it could 
trigger an interrupt to the LU's 
control-operator transaction program (see 
section "Control-Operator Transaction 
Program" on page 5.4-22) to allow that 
program to examine the new session-limit 
parameters and display them for the oper- 
ator. 
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PS Verb Router here 
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INITIALIZE _ 
SESSION _ 
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DISPLAY 
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SESSION_ 
PROC 


A 


Source-LU | 
Session—-Limit 
Services 


PROCESS __ 
SESSION _ 
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PROC 


Target—LU 
Session-Limit 
Services 


Manager 


Presentation Services for the 
Control Operator (PS.COPR) 


V Vv V V V V V 
Resources PS Resources PS Resources PS Resources 
Manager Verb Manager Verb Manager Verb Manager 

Router Router Router 


1 These routines are verb handlers for both local— and distributed—function session—-limit verbs. 


LEGEND: . 
---> Call/return relationship (within a process) 
< > Send/receive relationship (between processes ) 


Figure 5.4-13. 


PS.COPR COMPONENTS 


Figure 5.4-13 shows the structure of PS.COPR. 
Its main components are: 


¢ The control-operator-verb router (repres- 
ented in the figure by the connecting 
arrows from the PS verb router to the 
various verb-handler routines ) 


e =636A verb handler for each verb (e.g., ACTI- 
VATE_SESSION_PROC , DEFINE_PROC, DIS- 
PLAY_PROC, INITIALIZE_SESSION_LIMIT_PROC, 
PROCESS_SESSION_LIMIT_PROC) 

for 


® Common  verb-processing routines 


groups of verbs: 
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Structure of Presentation Services for the Control Operator 


- 
{ 
\ 


_ Local session-limit services’ for 
single-session mode names and_ for 
mode name SNASVCMG (LO- 


CAL_SESSION_LIMIT_PROC) 


— Source-LU CNOS session-limit services 
(SOURCE_SESSION_LIMIT_PROC }) 


—-  Target-LU CNOS session-limit services 
(combined with PROC- 
ESS_SESSION_LIMIT_PROC) 


The session-limit-data lock manager that 
controls contention between source-LU 
session-limit services (running on behalf 
of a locally-issued verb) and target-LU 
session-limit services (running on behalf : 
of a remotely-issued verb). 


ee 


Verb Parameter Values 


LU_MODE_ MINIMUM_ 
SESSION_ CONWINNERS_ CONWINNERS_ Locally Activated 


CNOS Verb Router 


The control-operator verb router component is 
the root procedure of PS.COPR. It is invoked 
by the PS verb router (see Chapter 5.0) when 
a transaction program issues a 
control-operator verb. It forms part of the 
transaction-program process. It is passed 
the transaction-program-verb structure 
(TRANSACTION_PGM_VERB) from the PS_~ verb 
router, and passes this structure on to the 
corresponding verb handler. Upon regaining 
control from the verb handler, it returns to 
the PS verb router. 


LOCAL CONTROL-OPERATOR VERB PROCESSING 


Local-verb services comprises the verb han- 
dlers for two groups of local-function verbs: 
LU definition verbs and local session-control 
verbs. 


LU DEFINITION VERB PROCESSING 


The LU definition verbs include DEFINE and 
DISPLAY (see Figure 5.4-13). These verbs 


MINIMUM _ Polarity for 


allow an implementation to define and display 
the parameters that are: configuration depend- 
ent (i.e., the maximum number of sessions) 
and optional capabilities that are supported 
by the LU, the partner LUs, the MODES, and 
the transaction programs. 


The verb handler checks privilege to deter- 
mine that the requesting control-operator 
transaction program has DEFINE or DISPLAY 
privilege, as appropriate to the verb. It 
lucates the relevant data structure and its 
containing structures using the Keys provided 
as verb parameters. It provides a return 
code indicating whether the operation was 
performed successfully. 


The verb handler copies’ values from 
control-operator transaction program vari- 
ables into the LU data structures, or vice 
versa; the transaction program never’ has 
direct access or addressability to the LU 
data structures. 


Contention Polarity to be Used 


Polarity Negotiation 
for Remotely Activated 
Sessions 


LIMIT SOURCE TARGET Sessions 
0 % % 
1 0 0 contention winner 
1 1 0 contention winner 
1 0 1 contention loser 
l 1 1 


2 or more 


LEGEND: 
* any value 


parameter combination not allowed 


accept partner choice 
contention winner 


accept partner choice 
parameter combination not allowed 


parameter combination not allowed 


Figure 5.4-14. Single-Session Contention Polarity 


Parameters 


LOCAL SESSION-CONTROL VERB PROCESSING 


The session-activation verb handlers (e.g.>, 
ACTIVATE_SESSION_PROC) have an interprocess 
(send/receive ) relationship with the 
resources manager for exchanging the 
session-activation and -deactivation records. 


The local session-limit services component 
(LOCAL_SESSION LIMIT PROC) provides the func- 
tions of the session-limit verbs for both 
single-session mode names and “(for the 
parallel-session mode name SNASVCMG, 1.e., 
the SNA-defined mode name used by _ CNOS. 
(Even though SNASVCMG-mode-name sessions are 


Determined by Minimum-Contention-Winner-Limit 


parallel sessions, local verbs are used to 
initialize--to fixed session limits--and to 
reset the SNASVCMG mode name, because a ses- 
sion with this mode name must be activated 
before the first CNOS command and reply can 
be sent.} This component has an interprocess 
(send/receive ) relationship with the 
resources manager to notify RM of limits 
changes. 


INITIALIZE SESSION LIMIT: When this verb is 


issued for a single-session mode name or for 
mode name SNASVCMG, local session-limit serv- 
ices checks session-limit constraints and 
sets the (LU,mode) session limit at the local 
LU. The partner LU does not participate in 
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setting the limits. Local session-limit 
services sends a change-sessions notification 
to the resources manager so _ that the 
resources manager may request activation of 
the allowed sessions according to its 
session-activation algorithm. 


For single-session mode names » local 
session-limit services also determines the 
contention polarity to be used when a session 
is activated by the local LU and determines 
the contention-polarity negotiation rule to 
be used when a session is activated by a 
partner LU. It determines these settings 
from the minimum-contention-winner limit 
parameters of the verb, as specified in Fig- 
ure 5.4-14 on page 5.4-24. 


In the figure, the first three columns list 
possible combinations of verb parameter val- 
ues. The next column (locally activated ses- 
sions ) specifies the corresponding 
contention-polarity choice that will be sent 
in a BIND RU issued by the local LU; the 
partner LU may negotiate contention-winner to 
contention-loser (1.e., make the partner LU 
the contention winner), but not the reverse. 
The next column (remotely activated sessions ) 
specifies the contention-polarity that will 
be sent in the response issued by the local 
LU to a BIND froma partner LU. The local LU 
may change a received contention-loser into a 
contention-winner, but not the reverse. The 
last two columns also indicate those combina- 
tions of verb parameter values that are 
invalid with single-session mode names. 


For the parallel-session mode name SNASVCMG, 
the verb parameters have their usual inter- 
pretation, but the only accepted values are: 
(LU,mode ) session limit = 2») minimum 
contention-winner limit (source) = 1, minimum 
contention-winner limit (target) = 1. 


RESET SESSION LIMIT: When this verb is 
issued for a single-session mode name or for 
mode name SNASVCMG, local session-limit serv- 
ices checks’ session-limit constraints and 
sets the (LU,mode) session limit to 0 at the 
local LU. It also sets the drain specifica- 
tion for the local and remote LUs. The part- 
ner LU does not participate in setting these 
limits. Local session limit services sends a 
change-sessions notification to the resources 
manager so that the resources manager will 
deactivate the specified sessions according 
to its drain and session-deactivation algo- 
rithms. 


For mode name SNASVCMG, local session-limit 
services also verifies that all other mode 
names for the specified partner LU are fully 
reset, 1.e., have (LU,mode) session limit = 0 
and drain state NO. If so, it sets the ses- 
sion limits for mode name SNASVCMG to O and 
notifies RM to deactivate the 
SNASVCMG-mode-name sessions; otherwise, it 
does not change the limits but sets the 
appropriate return code. 


ACTIVATE SESSION: For this verb, if the TP 
has session control privilege, the verb han- 
dler sends a session-activation request to 
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the resources manager, and receives a reply 
record indicating whether the session was 
successfully activated. 


DEACTIVATE SESSION: For this verb, if the TP 
has session control privilege, PS.COPR sends 
a session-deactivation request to the 
resources manager; the resources manager 
sends no reply, as session deactivation is 
assured. 


SESSION-LIMIT SERVICES AT THE SOURCE LU 


Source-LU session-limit services (SSLS) proc- 
esses CNOS verbs issued at the source LU. It 
forms a part of the source-LU 
transaction-program process that includes the 
control-operator transaction program. It is 
invoked via the presentation services (PS) 
verb router and PS.COPR when 
control-operator transaction program issues al 
CNOS verb, and returns — to 
control-operator transaction program via the 
routers upon completing processing. 


SSLS interacts with other LU components as 
follows (see Figure 5.4-15). 


A verb-handling routine corresponding to the 
specific verb (INITIALIZE_SESSION_LIMIT_PROC, 
CHANGE_SESSION_LIMIT_PROC, or 
RESET_SESSION_LIMIT_PROC), receives the verb 
parameters from the PS.COPR router. 
invokes the common = session-limit services 
routine SOURCE_SESSION_LIMIT_PROC. It 
returned the same structure with a return 
code, which it passes back to the PS.COPR 
router. 


SOURCE_SESSION_LIMIT_PROC is passed the CNOS 
verb parameters which it returns updated with 
a return code when its processing is com- 
plete. It performs the remainder of SSLS 
processing, as follows. 


e It verifies that the program issuing the ~~ 


verb is privileged to issue CNOS verbs. | 


e It allocates a conversation with the tar- 
get. 


e Using that conversation, it sends a CNOS 
command record and receives a CNOS reply 
record 


e It invokes the session-limit-data-lock 


manager (see "Session-Limit Data Lock 
Manager" on page 5.4-30) to prevent 
simultaneous updating of the same 


(LU,mode) entry, or entries, and to 


resolve races. 


e It updates the (LU,mode) entry with the 
accepted session-limit parameters. 


° If necessary,» it notifies the resources 


manager to increase or decrease the oar i 


rent number of sessions. 
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---> Call/return relationship (within a process) 
> Send/receive relationship (between processes ) 
‘ares > Access to shared data (within the LU) 

<amam> =Transaction program interaction (between LUs) 
1 See Chapter 5.1 for these interactions. 
@ PS router detail has been omitted. 
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Privilege Checking 


SSLS examines the source-LU's transaction 
program list to determine whether’ the 
control-operator transaction program is 
authorized to issue CNOS verbs, 1.e., whether 
it has change-number-of-sessions privilege. 


If not, SSLS causes the verb to fail. 


(Since the target transaction program has a 
privileged transaction-program name, i1.e.>, 
TPN less than X‘'40', presentation services 
for conversations also verifies, by checking 
the transaction-program list at the source 
LU, that the transaction program issuing the 
ALLOCATE is allowed to invoke privileged pro- 
grams. } . 


CNOS Conversation Allocation 


SSLS allocates a conversation with the target 
LU to exchange the CNOS command and reply. 
The conversation requires only conversation 
verbs in the base set, but an implementation 
may use verbs and parameters from the 
locally-supported "performance" option sets 
that do not require remote support (see SNA 
Transaction Programmer's Reference Manual for 
LU Type 6.2}. 


The following subsections discuss the allo- 
cation parameters for the conversation. 


LU name: SSLS uses the target LU name sup- 
plied by the CNOS verb. 


Mode name: SSLS uses an 
implementation-defined algorithm to select a 
mode name for the CNOS conversation; for 
example, the algorithm can select a mode name 
for which a session is currently active and 
available. If no session is available on any 
other implementation-selected mode name, SLSS 
uses the SNA-defined mode name SNASVCMG. It 
also uses SNASVCMG for the first CNOS verb 
issued by the LU, 1.e., when no sessions are 
active for other mode names and the session 
limits for all mode names (except SNASVCMG) 
are all O. 


(The operator previously initializes the ses- 
sion limits for mode name SNASVCMG~ to 
MAX_SESSIONS( 2), MIN_CONWINNERS_SOURCE(1), 
and MIN_CONWINNERS_TARGET(1), so that the 
source LU may always succeed’ in activating 
one contention winner session to send the 
CNOS command and reply. ) 


Type: Basic Conversation 

Transaction Program Name: SSLS establishes 
the conversation with the CNOS_~ service 
transaction program, whose SNA-defined trans- 


action program name (TPN) is X'06F1', at the 
target LU. 


Security: 


The CNOS conversation uses SECURI- 
TY (NONE ). | 


Synchronization Level: The CNOS conversation 


uses SYNC_LEVEL(NONE ). 
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Recovery Level: The CNOS conversation uses 
RECOVERY_LEVEL(NONE ). 


Program Initialization Parameters: 
conversation does not use program initializa- 
tion parameter data, 1.e., 1% uses PIP(NO). 


GDS Variable 


SSLS builds a CNOS command containing the 
verb and parameter information passed from 
the CNOS service transaction program and 
sends it to the target transaction program. 
The Change Number of Sessions GDS variable 
and the CNOS command and reply are described 
in SNA Formats. It receives from the target 
transaction program a similar CNOS reply con- 
taining a reply code that indicates either 
that the command was accepted or the reason 
for its rejection. 


\ 


\ 


A, 


CNOS Record Flows 


SSLS generates a conversation between the 
source-LU and the target-LU transaction pro- 
grams. The sequence of conversation verbs 
issued by SSLS», and the complementary verbs 
issued by the partner program SES- 
SION_LIMIT_SERVICES TARGET, are shown in Fig- 
ure 5.4-3 on page 5.4-9. 


Errors ( 


SSLS analyzes the CNOS verb parameters for 
transaction program errors, checks the return 
codes from conversation verbs for conversa- 
tion errors such as session failure or proto- 
col violation, and analyzes the CNOS reply 
for target-detected errors or changes’ to 
negotiable parameters, and determines the 
proper return code for the CNOS verb. 


If conversation failure (session outage 
occurs, the source LU retries the CNOS com, 


° . ~~ 
mand as described in "Recovery from Conversa- 


tion Failure" on page 5.4-20. 
Update (LU,mode) Entry 


If the command and reply exchange is_ com- 
pleted without error, SSLS updates’ the 
session-limit parameters for the specified 
(LU,mode) entry using the new values of 
LU MODE SESSION LIMIT, MIN _CONWINNERS SOURCE , 
MIN_CONWINNERS_TARGET, | RESPONSIBLE, = and 
DRAIN TARGET from the reply record. If the 
command specifies MODE_NAME(ALL), the limits 
for all mode names defined for the specified 
LU name, except the SNA-defined mode name 
SNASVCMG, are updated. SSLS then invokes the 
session-limit-data-lock manager to unlock the 
entries it locked (see "Session-Limit Da 

Lock Manager" on page 5.4-30). [ 
The new limits are enforced by the resources 
manager (see "Chapter 3. LU Resources Manag- 


The CNOS— 
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—_ 
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rd 
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er") and by the session manager (see "Chapter 
4. LU Session Manager"). 


If the CNOS command action is Set, or if it 
designates the source LU as responsible for 
session deactivation, SSLS issues a 
CHANGE_SESSIONS request, identifying the 
affected LU name and mode names, to the 
resources manager (RM). If MODE_NAME(ALL) is 
specified, SLSS sends a separate 
CHANGE_SESSIONS request for each mode name 
except mode name SNASVCMG. 


The CHANGE_SESSIONS request notifies RM that 
the session limit parameters have changed and 
that, as a consequence, RM may make changes 
to the number of sessions. RM determines the 
actual changes to be made to the session 
count and issues appropriate requests to the 
session manager to activate or deactivate 
sessions. 


Return to the Transaction Program 


When the above functions are completed, SSLS 
returns to the control-operator transaction 
program, passing back the appropriate return 
code in the transaction-program-verb struc- 
ture. 


SESSION-LIMIT SERVICES AT THE TARGET LU 


Target-LU session-limit services (TSLS) proc- 
esses the CNOS verbs issued at the target LU. 
It functions in a manner complementary to 
SSLS (see "Session-Limit Services at the 
Source LU" on page 5.4-25). It forms a part 
of the target-LU transaction-program process 
that includes the CNOS service transaction 
program. It is invoked via the presentation 
services (PS) verb router and the PS.COPR 
router when the CNOS service transaction pro- 
gram issues the PROCESS SESSION LIMIT verb; 
it returns to the CNOS service transaction 
program upon completion of processing. 


TSLS interacts with other LU components as 
follows (see Figure 5.4-16). 


e It receives the transaction-program-verb 
structure representing the PROC- 
ESS _SESSION_LIMIT verb 


When its processing is complete, it 
returns to the CNOS service transaction 
program, passing back the 
transaction-program-verb structure 
updated with a return code and the iden- 
tity of the affected (LU,mode) entries. 
(The latter may be used by the implemen- 
tation to inform the control operator of 
the changes. ) 


e It determines whether the issuing trans- 
action program is the CNOS service trans- 
action program (TPN=X'06F1') and has the 


change-number-of-sessions privilege. If 
not, TSLS abnormally terminates the 
transaction program, which causes the LU 
to issue DEALLOCATE TYPE(ABEND) on the 
conversation. 


e It communicates with SSLS at the source 
LU, using the conversation with which the 
CNOS service transaction program was 
attached, by issuing conversation verbs 
to presentation services for conversa- 
tions. 


e It receives a CNOS command from the 
source LU, changes the source LU's 
requested session-limit parameters to 
values acceptable to the target LU, if 
necessary, and sends a CNOS reply, with 
the same format, back to the source LU. 


e It invokes the session-limit-data-lock 
manager (see "Session-Limit Data Lock 
Manager" on page 5.4-30) to prevent 
simultaneous updating of any (LU,mode) 
entry. 


e It updates the affected (LU,mode ) 
entries. | 


e If necessary, it notifies the resources 
manager to increase or decrease the cur- 
rent number of sessions. 


CNOS Reply 


TSLS receives from the source-LU transaction 
program a CNOS command record containing the 
verb and parameter information passed from 
the control-operator transaction program. It 
builds a similar CNOS reply record containing 
the acceptable values of the negotiable 
session-limit parameters--see "Session-Limit 
Parameter Negotiation" on page 5.4-28--and a 
reply code, which either indicates that the 
command was accepted or gives the reason for 
its rejection, and sends it to the source LU. 


Session-Limit Parameter Negotiation 


TSLS executes an  implementation-determined 
algorithm to accept or modify the negotiable 
session-limit parameters received from the 
source LU, subject to the negotiation rules 
given below. It sets the Reply Modifier 
field in the CNOS reply to indicate whether 
all the parameters were accepted as received 
or whether any were negotiated to new values, 
and sends it with the received or modified 
values to the source LU in the CNOS reply. 
(The source LU accepts any modified values 
that satisfy the negotiation rules. ) 


The negotiation rules are as follows. (In 
the formulas, variables prefixed with C_ 
refer to values of verb parameters specified 
by the source LU in the CNOS command record; 
variables prefixed with R_ refer to values of 
these parameters as modified by the target LU 
and returned in the CNOS reply record. ) 
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LEGEND: 

---> Call/return relationship (within a process) 

< > Send/receive relationship (between processes ) 
»....> Access to shared data (within the LU) 

<s88E> Transaction program interaction (between LUs ) 


1 See Chapter 5.1 for these interactions. 
* PS router detail has been omitted. 


Figure 5.4-16. Target-LU Component Interactions for CNOS 


If the command action is Set (INITIALIZE_ or returning an abnormal reply with 
CHANGE_SESSION_LIMIT verb issued): reply-modifier value abnormal--(LU ,mode)—~ 
session limit is 0. The LU also has th 
°e If the current (LU,mode) session count is option to issue DEALLOCATE TYPE(ABEND.__~— 
0; then, based on an for the conversation. Both LUs_ then 
implementation-defined decision, the LU ignore the session-limit parameters of 
may refuse to accept the command by the reply; they do not change the current 
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( 


( 


\ 
C. 


session-limit parameters in the 
(LU,mode) entry. 
e The target LU may decrease 


LU_MODE_SESSION_LIMIT to a lower number 
of sessions, but not to 0, 1.e., the new 
value satisfies: 


O < R_LU_MODE_SESSION_LIMIT < 
C_LU_MODE_SESSION_LIMIT. 


e If the proposed source contention winners 
(C_MIN_CONWINNERS SOURCE ) exceeds 
R_LU_MODE_SESSION_LIMIT/2, the target LU 
may change MIN_CONWINNERS SOURCE to any 
lower value not less than 
R_LU_MODE_SESSION_LIMIT/2 rounded down- 
ward, 1.e., the new value satisfies: 


C_MIN_CONWINNERS SOURCE > 
R_MIN_CONWINNERS SOURCE > 


MIN(C_MIN_CONWINNERS_SOURCE > 
R_LU_MODE_SESSION_LIMIT/2). 


e The target LU may change its own minimum 
contention-winner limit 
(R_MIN_CONWINNERS_ TARGET) to any value 
not exceeding the difference between the 
total session limit and 
MIN_CONWINNERS SOURCE, 1.e., the new val- 
ue satisfies: 


© < R_MIN_CONWINNERS TARGET < 


(R_LU_MODE_SESSION_LIMIT - 
R_MIN_CONWINNERS_SOURCE ). 


° The target LU may change RESPONSIBLE to 
SOURCE. 


If the command action 1s Close for only one 
mode name (RESET_SESSION_LIMIT 
(MODE_NAME(ONE,...) 1ssued): 


e If the (LU,mode) session count is 0 and 
the current drain state is NO, then; 
based on an implementation-defined deci- 
sion, the target LU may refuse to accept 
the command by returning an = abnormal 
reply with reply modifier abnor- 
mal--(LU,mode) session limit is 0. Both 
LUs then ignore the session-limit parame- 
ters of the reply; they do not change the 
current session-limit parameters in the 
(LU,mode) entry. 


¢ The target LU may change RESPONSIBLE to 
SOURCE. 


e The target LU may change its own drain 
action (DRAIN_TARGET) from YES to NO. 


e The target LU does not change 
DRAIN_SOURCE. 


If the command action is Close for all mode 
names (RESET_SESSION_LIMIT (MODE_NAME( ALL ) 
issued): 


e If the (LU,mode) session count is 0 and 
the current drain state is NO for all 


mode names with the partner LU, then, 
based on an implementation-defined deci- 
sion, the target LU may refuse to accept 
the command by returning an_= abnormal 
reply with reply modifier abnor- 
mal--(LU,mode) session limit is 0. Both 
LUs then ignore the session-limit parame- 
ters of the reply; they do not change the 
current session-limit parameters in the 
(LU,mode) entry. 


e The target LU may change RESPONSIBLE to 
SOURCE. If so, it changes all mode names 
not already at SESSION_LIMIT = 0 to the 
same (SOURCE) responsibility. 


° The target LU does not send a_ changed 
value for DRAIN_TARGET in the reply, but 
echoes the value received. Nevertheless, 
if the command specifies 
DRAIN_TARGET(YES), and the current ses- 
sion limit is not zero, the target LU may 
set its local drain state for any mode 
names to either YES or NO, regardless of 
the previous drain state. If the current 
session limit is already zero and the 
drain state is no, the drain state for 
that mode is left unchanged. 


e The target LU does not change 
DRAIN_SOURCE. 


Errors 


If TSLS detects a condition that precludes 
performing the nominal action (e.g.» a race 
condition or unrecognized mode name), but 
that does not violate architectural rules, it 
sends an abnormal reply with the appropriate 
reply modifier (see SNA Formats for 
reply-modifier codes). 


If it detects an invalid command from the 
source LU, e.g.» undefined or disallowed 
parameter values, it treats this as a proto- 
col violation. TSLS does not change the CNOS 
parameters or send ae reply, but instead 
issues DEALLOCATE TYPE( ABEND). TSLS also 
reports any errors detected to the CNOS serv- 
ice transaction program via the 
transaction-program-verb structure. 


Other Interactions 


Other TSLS interactions are similar to the 
corresponding interactions of SSLS. 


SESSION-LIMIT DATA LOCK MANAGER 
Locking the (LU,mode) Entry 


The session-limit services routines invoke a 
shared . component » SES- 
SION_LIMIT_DATA_LOCK_MANAGER (SLDLM), to pre- 
vent simultaneous access to an (LU,mode) 
entry, to detect races, and to resolve 
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double-failure race conditions, as described 
in "CNOS Race Resolution" on page 5.4-14. 


SLDLM is a shared routine, invoked from both 
SSLS and TSLS, that maintains the 
session-limit data lock. A session-limit 
data lock exists for each (LU,mode) entry. 
It is in one of the following states: 


UNLOCKED: No CNOS component is_ currently 
using the (LU,mode) entry. The 
lock is reset to this state whenev- 
er the process that locked it com- 
pletes processing. 


LOCKED_BY_SOURCE: SSLS has locked the 


(LU,mode) entry to process a CNOS 
command issued at the local LU. 
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The lock had previously been in 
UNLOCKED state. a 


LOCKED_BY_TARGET: TSLS has locked the ~—" 
(LU,mode) entry to process a CNOS 
command issued at a remote LU. The 
lock had previously been in 
UNLOCKED state. 


LOCK_DENIED: While the lock was in 
LOCKED_BY_SOURCE state, TSLS 
attempted to lock it on behalf of a 
remotely-issued verb. TSLS was 
refused. 


This state allows SSLS to determine 
whether a double- failure race 
occurred. 


VERB-ROUTING PROCEDURE 


< 


PS _COPR 


FUNCTION: This procedure receives all control-operator verbs issued by the transaction 
program and routes the input to the appropriate procedure for processing. It 
is invoked by» and returns to, the presentation-services verb router and forms 


part of the transaction-program process. 


INPUT: CNOS verb parameters-- received from caller, updated by called procedures 
OUTPUT: Updated return code and verb-specific returned parameters 
C . Referenced procedures, FSMs,» and data structures: 
= INITIALIZE_SESSION_LIMIT_PROC page 5.4-33 

CHANGE_SESSION_LIMIT_PROC page 5.4-35 
RESET_SESSION_LIMIT_PROC page 5.4-34 
PROCESS SESSION _LIMIT_PROC page 5.4-57 
ACTIVATE_SESSION_PROC page 5.4-36 
DEACTIVATE_SESSION_PROC page 5.4-37 
DEFINE PROC page 5.4-38 
DISPLAY_PROC page 5.4-39 
DELETE_PROC page 5.4-40 


Select based on type of verb parameters: 

When INITIALIZE_SESSION_LIMIT 

Call INITIALIZE_SESSION_LIMIT_PROC with the verb parameters (page 5.4-33). 
When CHANGE_SESSION_LIMIT 

Call CHANGE_SESSION_LIMIT_PROC with the verb parameters (page 5.4-35). 
When RESET_SESSION_LIMIT 

Call RESET_SESSION_LIMIT_PROC with the verb parameters (page 5.4-34). 
When PROCESS_SESSION_LIMIT 

Call PROCESS_SESSION_LIMIT_PROC with the verb parameters (page 5.4-57). 
When DEACTIVATE_SESSION 

Call DEACTIVATE_SESSION_PROC with the verb parameters (page 5.4-37). 
When ACTIVATE_SESSION 

Call ACTIVATE_SESSION_PROC with the verb parameters (page 5.4-36). 
When DEFINE_LOCAL_LU, DEFINE_REMOTE_LU, DEFINE_MODE, or DEFINE_TP 

Call DEFINE_PROC with the verb parameters (page 5.4-38). 
When DISPLAY_LOCAL_LU,' DISPLAY_REMOTE_LU, DISPLAY_MODE, or DISPLAY_TP 

Call DISPLAY_PROC with the verb parameters (page 5.4-39). 
When DELETE 

Call DELETE_PROC with the verb parameters (page 5.4-40). 


\ 


( 


C 
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VERB HANDLERS 


INITIALIZE_SESSION_LIMIT_PROC 


FUNCTION: This procedure is called by PS_COPR;, the control-operator verb router, when a 


transaction program issues an INITIALIZE_SESSION_LIMIT verb. 


to the original caller. 


INPUT: INITIALIZE_SESSION_LIMIT verb parameters from caller; CNOS RETURN_CODE from 


LOCAL_ or SOURCE_SESSION_LIMIT_PROC 


OUTPUT : RETURN_CODE of INITIALIZE_SESSION_LIMIT to caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_SESSION_LIMIT_PROC page 5.4-45 
LOCAL_SESSION_LIMIT_PROC page 5.4-41 


If this transaction program is authorized to issue the CNOS verb then 
Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


For parallel session connections, an LU may elect not to expose the 
MIN_CONWINNERS_TARGET parameter at the control-operator protocol 


boundary. In this case, the implementation may choose any value that 
satisfies the description of this parameter in SNA _ Transaction Pro- 


grammer 's Reference Manual for LU Type 6.2. 


If the specified LU is not defined as a partner LU for this LU then 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 


Else 
If the type of connection is parallel-sessions 
and the mode name is not SNASVCMG then 
Call SOURCE_SESSION_LIMIT_PROC (page 5.4-45)> 
with the verb parameters, to begin the negotiation phase of the CNOS 
process. 


Else (local control-operator verb) 
Call LOCAL_SESSION_LIMIT_PROC (page 5.4-41), 
with the verb parameters, to perform the CNOS action solely at the 
local LU. 
Else 
Set CNOS RETURN_CODE to PROGRAM_ PARAMETER_CHECK. 
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It determines 
the connection type (single or parallel). If the connection is single-session 
or the mode name is SNASVCMG, it passes the CNOS verb parameters 
LOCAL_SESSION_LIMIT_PROC; if the connection is parallel-session, it passes the 
CNOS verb parameters to SOURCE_SESSION_LIMIT_PROC. It passes the return code 


RESET_SESSION_LIMIT_PROC 


RESET_SESSION_LIMIT_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator verb router, when a 
transaction program issues a RESET_SESSION LIMIT verb. It determines the con- 
nection type (single or parallel). If the connection is single-session or the 
mode name is SNASVCMG; it passes the CNOS verb’ parameters’~- to 
LOCAL_SESSION_LIMIT_PROC; if the connection is parallel-session, it passes the 


CNOS verb parameters to SOURCE_SESSION_LIMIT_PROC. It passes the return code 
to the original caller. 


INPUT: RESET_SESSION_LIMIT verb parameters from caller; CNOS RETURN_CODE from LOCAL_ 
or SOURCE _SESSION_LIMIT_PROC 


OUTPUT : RETURN_CODE of RESET_SESSION_LIMIT verb to caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_SESSION LIMIT PROC page 5.4-45 
Lacks LOCAL_SESSION_LIMIT_PROC page 5.4-41 
C | CHANGE_ACTION page 5.4-43 


If this transaction program is authorized to issue the CNOS verb then 
Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


For parallel-session connections, an LU may elect not to expose the 
DRAIN_TARGET, and RESPONSIBLE parameters at the control-operator pro- 
tocol boundary. In this case, the implementation provides default 
values for these parameters consistent with the description on page 
5.4-21. 


os For single-session connections, the RESPONSIBLE parameter on the verb 
; is not used. It is forced to SOURCE. 
ae 


For the SNA-defined mode name, SNASVCMG, the |§DRAIN_SOURCE, 
DRAIN_TARGET, and RESPONSIBLE parameters on the verb are not used. 
They are forced to NO, NO, SOURCE, respectively. 


If the specified LU is not defined as a partner LU for this LU then 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 


Else 
a If the type of connection is parallel-sessions 
: and the mode name is not SNASVCMG then 
q | Call SOURCE_SESSION_LIMIT_PROC (page 5.4-45), 
with the verb parameters, to begin the negotiation phase of the CNOS process. 
If FORCE = YES is specified on the RESET_SESSION_LIMIT verb then 
If the CNOS return code indicates ALLOCATION_ERROR-ALLOCATION_FAILURE_NO_RETRY, 
LU_MODE_SESSION_LIMIT_CLOSED, RESOURCE_FAILURE_NO_RETRY or 
UNRECOGNIZED_MODE’NAME then 
Change RESPONSIBLE to SOURCE. 
Call CHANGE_ACTION (page 5.4-43) with the CNOS request to 
update the limits in the MODE structure(s) for the source LU and notify RM. 
Set the CNOS return code to OK-FORCED. 


Else (local control-operator verb) 
Call LOCAL_SESSION_LIMIT_PROC (page 5.4-41), 
with the verb parameters, to perform the CNOS action solely at the local LU. 


Else 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 
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CHANGE_SESSION_LIMIT_PROC 


5.4-36 


CHANGE_SESSION_LIMIT_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator verb router, when a 
transaction program issues a CHANGE_SESSION_LIMIT verb. It 
verb parameters to SOURCE_SESSION_LIMIT_PROC and passes the 


the original caller. 


INPUT: _CHANGE_SESSION_LIMIT parameters from callers CNOS~ RE 
SOURCE_SESSION_LIMIT_PROC 


OUTPUT : RETURN_CODE of CHANGE_SESSION_LIMIT to caller 


Referenced procedures, FSMs, and data structures: 
SOURCE_SESSION_LIMIT_PROC 


If the control-operator transaction program, at the source LU, 
is not authorized to issue the CNOS verb then 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


Else 


Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


An LU might elect not to expose the RESPONSIBLE 


passes the CNOS 
return code to 


TURN_CODE 


page 5.4-45 


and 


MIN_CONWINNERS_TARGET parameters at the control-operator protocol 


boundary. In this case, the implementation provides default 


for these parameters consistent with the description on page 
and the parameter specification in SNA Transaction Programmer's 


If the specified LU is not defined as a partner for this LU then 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 


Else 


If the type of connection is parallel-sessions and the mode name is not SNASCVMG then 


Call SOURCE_SESSION_LIMIT_PROC (page 5.4-45), 


with the verb parameters, to begin the negotiation phase of the CNOS process. 


Else 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 
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ACTIVATE_SESSION_PROC 


ACTIVATE_SESSION_PROC 


FUNCTION: 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues an ACTIVATE_SESSION' verb. It sends = an 
RM_ACTIVATE_SESSION request to RM to activate a session, and receives the 
reply indicating whether the session was activated. 


The CNOS verb (ACTIVATE_SESSION), the reply from RM (RM_ACTIVATE_SESSION ) 


The request to RM (RM_ACTIVATE_SESSION), RETURN_CODE of ACTIVATE_SESSION verb 


This procedure has addressability to RM via PS_PROCESS DATA.LU_ID. 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
PS_PROCESS_DATA page 5.0-24¢ 
RM_ACTIVATE_SESSION page A-16 


RM_SESSION_ACTIVATED page A-22 


Verify that the verb parameters specified satisfy the 
parameter values for the ACTIVATE_SESSION verb described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Select based on the result of parameter verification: 
When transaction program is not authorized to issue ACTIVATE_SESSION 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 
When a parameter error is identified 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
When all parameters are correct 
Create an RM_ACTIVATE_SESSION request record. 
Set RM_ACTIVATE_SESSION.TCB_ID to PS_PROCESS_DATA.TCB_ID to identify 
the transaction control block describing this instance of PS. 
Set RM_ACTIVATE_SESSION.LU_NAME to the LU name specified in the CNOS verb. 
Set RM_ACTIVATE_SESSION.MODE_NAME to the mode name specified in the CNOS verb. 
Send RM_ACTIVATE_SESSION request to RM. 
Receive RM_SESSION_ACTIVATED reply from RM. 
Set CNOS RETURN_CODE according to the return code in the 
RM_SESSION_ACTIVATED reply received from RM. 
IF this is a single session and cornwinner received (as it was requested) then 
Set the secondary code to OK.AS_ SPECIFIED. 


Else 


Set the secondary code to OK.AS NEGOTIATED. 
Destroy the RM_SESSION_ACTIVATED record. 
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DEACTIVATE_SESSION_PROC 


DEACTIVATE_SESSION_PROC 


FUNCTION: 


INPUT : 


OUTPUT : 


NOTE : 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues a  DEACTIVATE_SESSION verb. It sends an 
RM_DEACTIVATE_SESSION request to RM to deactivate a session. The calling TP 
may be given control back before the session is actually deactivated. 


The DEACTIVATE_SESSION verb 


Request to RM (RM_DEACTIVATE_SESSION), RETURN_CODE of DEACTIVATE_SESSION verb 


This procedure has addressability to RM via PS_PROCESS DATA.LU_ID. 


Referenced procedures, FSMs, and data structures: 


RM page 3-19 
PS_PROCESS_DATA page 5.0-24¢ 
RM_DEACTIVATE_SESSION page A-17 


Verify that the verb parameters specified satisfy the 

parameter values for the ACTIVATE_SESSION verb described in 

SNA Transaction Programmer's Reference Manual for LU Type 6.2. 

If transaction program is authorized to issue DEACTIVATE_SESSION then 
Set the CNOS RETURN_CODE to OK. 
Create a RM_DEACTIVATE_SESSION request record. 
Set RM_DEACTIVATE_SESSION.TCB_ID to PS PROCESS DATA.TCB_ID to identify 

the transaction control block describing this instance of PS. 

Set RM_DEACTIVATE_SESSION.SESSION_ID to the SESSION_ID specified in the CNOS verb. 
Set RM_DEACTIVATE_SESSION.TYPE to the TYPE specified in the CNOS verb. 
Send RM_DEACTIVATE_SESSION request to RM. 


Else 


Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 
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DEFINE_PROC 


4 DEFINE_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues any of the DEFINE verbs’ (DEFINE_LOCAL_LU, 
DEFINE_REMOTE_LU, DEFINE_MODE, or DEFINE_TP). It is used to initialize or 


modify attributes of the LUCB, PARTNER_LU, MODE, and TRANSACTION _PROGRAM data 
structures. 


INPUT: The DEFINE verb parameters 


OUTPUT: The attributes of the data structure are defined with the specified values. 


NOTE: This verb may be used to define any other attributes of the LU that are mean- 
ingful for a given implementation. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 

PARTNER_LU page A-2 

me MODE page A-3 
C TRANSACTION_PROGRAM page A-5 


Verify that the verb parameters specified satisfy the 
parameter values for the DEFINE verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


If an ABEND condition is identified then 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


Else 


a The parameters specified are all valid attributes of the LUCB, PART- 
< NER_LU, MODE, or TRANSACTION_PROGRAM data structure. 


Assign values to the attributes of the data structure according to those 
specified on the DEFINE verb. 


( 


\ 
a 
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DISPLAY_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues any of the DISPLAY verbs (DISPLAY_LOCAL_LU, DIS- 
PLAY_REMOTE_LU, DISPLAY_MODE, or DISPLAY_TP). It is used to display attri- 
butes of the LUCB, PARTNER_LU, MODE, and TRANSACTION_PROGRAM data structures. 


The DISPLAY verb parameters 


The specified attributes of the data structure are displayed for the user. 


This verb may be used to display any other attributes of the LU that are mean- 
ingful for a given implementation. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 
TRANSACTION_PROGRAM page A-5 


Verify that the verb parameters specified satisfy the 
parameter values for the DISPLAY verb in 


If an ABEND condition is identified then 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


The parameters specified are all valid attributes of the LUCB, PART- 
NER_LU, MODE MODE, or TRANSACTION_PROGRAM data structure. 


~ 


Else 


Display the requested LUCB, PARTNER_LU, MODE, or TRANSACTION_PROGRAM 
attributes as they are currently defined. 
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DELETE_PROC 


DELETE_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues a DELETE verb. It is used to delete attributes of 
the LUCB, PARTNER_LU, MODE, and TRANSACTION_PROGRAM data structures. 

INPUT: The DELETE verb parameters 


OUTPUT: The data structure attributes are deleted. 


NOTE: This verb may be used to delete any other attributes that are meaningful for a 
given implementation. 


Referenced procedures, FSMs,» and data structures: 


LUCB page A-1l 
PARTNER_LU page A-2 
MODE page A-3 
TRANSACTION_PROGRAM page A-5 


Verify that the verb parameters specified satisfy the 
parameter values for the DELETE verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 
If an ABEND condition is identified then 

Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


The parameters specified are all valid attributes of the LUCB, PART- 
NER_LU, MODE, or TRANSACTION_PROGRAM data structure. | 


Delete the LUCB, PARTNER_LU, MODE, or TRANSACTION_PROGRAM attributes 
as specified on the DELETE verb. 


Else 
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LOCAL_SESSION_LIMIT_PROC 


5.4-42 


LOCAL_SESSION_LIMIT_PROC 


FUNCTION: This procedure is invoked by either of the following verb-specific CNOS proce- 
dures: INITIALIZE_SESSION_LIMIT, RESET_SESSION_LIMIT. It processes CNOS 


control-operator verbs that affect only the local LU: INITIALIZE_ and 


RESET_SESSION_LIMIT for single-session connections and for mode name SNASVCMG. 
INPUT: The CNOS source LU verb parameters from the calling procedure 


OUTPUT : Return code for the CNOS verb (CNOS RETURN_CODE ) 


NOTE : This procedure read-locks the MODE for the entire procedure. 


Referenced procedures, FSMs, and data structures: 


LOCAL_VERB_PARAMETER_CHECK page 5.4-42 
SVCMG_VERB_PARAMETER_CHECK page 5.4-43 
CHANGE_ACTION page 5.4-43 


Using the LUCB, determine the type of session possible 
with the partner LU, either single or parallel. 


If the type of connection is single session then 
Call LOCAL_VERB_PARAMETER_CHECK (page 5.4-42), 
with the CNOS verb parameters, to verify the verb paraneters. 


Else | 
Call SVCMG_VERB_PARAMETER_CHECK (page 5.4-43), with the CNOS verb 
parameters, to perform the appropriate parameter checks. 


If the check found no errors then 


Call CHANGE_ACTION (page 5.4-43), with the CNOS verb parameters, 
to change the session limits at the source LU according to the parameters specified. 
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LOCAL_VERB_PARAMETER_CHECK 


LOCAL_VERB_PARAMETER_CHECK 


This procedure performs validity checks on a CNOS verb for single-session con- 
nections, and it returns the CNOS-verb RETURN_CODE for any error detected. 


FUNCTION: 


INPUT: The CNOS source LU verb parameters, PARTNER_LU_LIST, and MODE_LIST 


OUTPUT: CNOS verb RETURN_CODE value 


Referenced procedures, FSMs, and data structures: 
LUCB 
MODE 


page A-1 
page A-3 


Verify that the specified verb parameters satisfy the single-session 
parameter values as described for this verb in 


Select based on result of parameter verification: 
When all parameters are correct 
Set the CNOS RETURN_CODE to OK--AS_SPECIFIED. 
When a program parameter check condition is identified as defined in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


When a parameter error is identified 
Set the CNOS RETURN_CODE for this verb to PARAMETER_ERROR. 


When the MODE.SESSION_LIMIT is not 0 


ON Set the CNOS RETURN CODE to LU_MODE_SESSION LIMIT_NOT_ZERO. 
Lo When all (LU,MODE) session limits to this single session partner LU are currently 0 
and the sum of all (LU,MODE) session limits to other partner LUs = the total 


session limit (in the LUCB) 
Set the CNOS RETURN_CODE for this verb to LU_SESSION_LIMIT_EXCEEDED. 


When the session limit specified exceeds the LOCAL_MAX_SESSION_LIMIT in the MODE 
Set the CNOS RETURN_CODE for this verb to REQUEST_EXCEEDS_MAX_ALLOWED. 
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SVCMG_VERB_PARAMETER_CHECK 


SVCMG_VERB_PARAMETER_CHECK 


eer et 


FUNCTION: This procedure performs validity checks on a CNOS verb for mode name SNASVCMG, 
and it returns the CNOS-verb RETURN_CODE for any error detected. 


INPUT: Transaction program verb parameters, PARTNER_LU_LIST, and MODE_LIST 


OUTPUT: CNOS verb RETURN_CODE value if any errors’ are detected; otherwise, OK is 
returned 


Referenced procedures, FSMs, and data structures: 
LUCB page A-1 
MODE page A-3 


Verify that the verb parameters specified satisfy the parameter values appropriate 
for parallel-session connections, as described in 


« 
Select, in order, based on result of parameter verification: 
When an program parameter check condition is identified as defined in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 
Set CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 
When a parameter error is identified 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
When the MODE .SESSION_LIMIT is not 0 : 
Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_NOT_ZERO. 
When the session limit specified could not be added without exceeding ao 
the session limit in the LUCB for the LU (page 5.4-4) ( | 
Set the CNOS RETURN CODE to LU_SESSION_LIMIT_EXCEEDED. cy 
CHANGE_ACTION © 
; : : ; . eS 
FUNCTION: This procedure is called when the LU accepts a valid (and negotiated, if nec- ( 
essary) CNOS command. This procedure updates the (LU,mode) entries for 2: 
affected mode names with the new session limit parameters. It decides wheth- 
er this LU is responsible for taking any action to change the session count, 
and, if so, sends a CHANGE_SESSIONS request to RM. 
The CNOS verb parameters specified, if the CNOS verb is local to this LU only; 
the new session limit parameters in the CNOS reply record, if the CNOS action 
is distributed; the role of the LU to be modified (source or target), PART- 
NER_LU_LIST and MODE_LIST 
OUTPUT: Session limits and drain state are updated in the MODE; CHANGE_SESSIONS to RM 
NOTE: This procedure locks the MODE for the entire procedure. 
See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for the 
session-limit parameters affected by each CNOS verb. 
This procedure has addressability to RM via PS_PROCESS _DATA.LU_ID. 

Referenced procedures, FSMs, and data structures: -_ 
RM page 3-19 ee 
CHANGE_SESSIONS page A-15 
PARTNER_LU page A-2 


MODE page A-3 
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CHANGE_ACTION 


Select based on whether one MODE or all MODEs with the PARTNER_LU are affected 
(see the MODE_LIST associated with the PARTNER_LU): 
When only one MODE is affected 
Update the session-limit parameters for the specified (LU, mode) entry 
(MODE .SESSION_LIMIT, MODE .MIN_CONWINNERS_LIMIT, MODE.MIN_CONLOSERS LIMIT, 
MODE .DRAIN_SELF, MODE.DRAIN_PARTNER, MODE.RESPONSIBLE) as they are applicable: 


( 


For single-session mode names and for mode name SNASVCMG, the session limit 
parameters affected are those specified on the particular CNOS verb and the 
changes are reflected in the source LU only. : 


MODE .MINCONWINNERS_LIMIT is set from MINCONWINNERS SOURCE specified in 


the CNOS command. MODE .MINCONLOSERS_LIMIT is set from 
MINCONWINNERS_TARGET specified in the CNOS command. 


For parallel-session connections defined with the partner LU, the session limit 
parameters affected are those specified on the CNOS reply and the changes are 
reflected as appropriate in both the source and the target LU (when this 

Se procedure is called from SOURCE_SESSION_LIMIT (or LOCAL_SESSION_LIMIT) and 
C > PROCESS _SESSION_LIMIT, respectively). 


At the source’ LU, MODE .MIN_CONWINNERS LIMIT is_ set from 
MIN_CONWINNERS_SOURCE specified in the CNOS reply and 


MODE .MIN_CONLOSERS_LIMIT is set from MIN_CONWINNERS TARGET specified 
in the CNOS reply. The reverse is true at the target LU. 


If the verb issued at the source LU is INITIALIZE_SESSION_LIMIT or CHANGE_SESSION_LIMIT, 
or, according to the responsible field of the CNOS reply (applicable only when the 
CNOS function is distributed), this LU is responsible for session deactivation then 


} Set CHANGE_SESSIONS.LU_NAME to PARTNER_LU.LOCAL_LU_ NAME. 
s Set CHANGE_SESSIONS.MODE_NAME to the affected mode name as specified on the 
CNOS verb. 

Set CHANGE_SESSIONS.DELTA to the difference between the LU_MODE_SESSION_LIMIT 
specified on the CNOS command or reply and the current MODE.SESSION_LIMIT. 

If the verb issued by the source LU is CHANGE_SESSION_LIMIT and the limit in the 
reply is less than the current session limit, or the verb issued by the source LU 
is the distributed function RESET_SESSION_LIMIT verb | MODE.DRAIN_SELF = NO then 

If the responsible field value in the CNOS reply specifies the current LU (which 
could be source or target) then 
Set CHANGE_SESSIONS.RESPONSIBLE’ to YES. 
Else 
C Set CHANGE _SESSIONS.RESPONSIBLE to NO. 


a Create a CHANGE_SESSIONS request record. 


Else (RESPONSIBLE value will not be significant to RM) 
Set CHANGE_SESSIONS.RESPONSIBLE to NO. 
Send the CHANGE_SESSIONS request to RM. 


When all MODEs are affected (in which case the verb issued by the source LU is 
RESET_SESSION_LIMIT ) 
Do the following for each MODE (except SNASVCMG) with the PARTNER_LU 
Set MODE.DRAIN_SELF and MODE.DRAIN_PARTNER based on the current 
session limit and the drain parameters of the CNOS reply. 

Set SESSION_LIMIT, MIN_CONWINNERS LIMIT and MIN_CONLOSERS_LIMIT to 0. 

If this LU is responsible for session deactivation | MODE.DRAIN_SELF = NO then 
Create a CHANGE_SESSIONS request record as described in detail above. 
Send the CHANGE_SESSIONS request to RM. 
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SOURCE_SESSION_LIMIT_PROC 


FUNCTION: 


OUTPUT : 


This procedure is invoked by any of the following verb-specific CNOS proce- 
dures: INITIALIZE _SESSION_LIMIT, CHANGE_SESSION_LIMIT, RESET_SESSION_LIMIT. 
It provides common’ overall processing of a = parallel-session  CNOS 
control-operator verb issued by a source LU control operator transaction pro- 
gram. It invokes other procedures to check the verb parameters for validity, 
detect and resolve race conditions with any other CNOS transaction, build a 
command record, allocate a conversation with the target LU, exchange command 
and reply records with the target LU, update the PARTNER_LU_LIST and MODE_LIST 
with the new session limit parameters, and, if necessary, request the 
resources manager to activate or deactivate sessions. If errors are detected 
at any point, it sKips subsequent steps and cleans up from previous steps. 
It passes a RETURN_CODE to the calling procedure indicating success or a 
failure reason. 


CNOS source LU verb parameters, from the calling procedure; the CNOS reply 
from the target LU, via §SOURCE_CONVERSATION_CONTROL; the (LU,mode) entries 
with the session limits in the MODE, PARTNER_LU_LIST and MODE_LIST, and other 
CNOS parameters; the lock to control contention for the PARTNER_LU_LIST and 
MODE_LIST by CNOS transaction processes, and to resolve CNOS races (maintained 
by SESSION_LIMIT_DATA_LOCK_MANAGER ) 


Return code for the CNOS verb, CNOS RETURN_CODE ; 
MODE .CNOS_NEGOTIATION_IN PROGRESS and MODE.LIMIT_BEING_ NEGOTIATED; procedure 
SOURCE_CONVERSATION allocates and deallocates a conversation with the target 
LU and issues conversation verbs; specified (LU,mode) entries updated via 
CHANGE_ACTION in the MODE; CHANGE_SESSIONS issued to RM—via CHANGE_ACTION 


Referenced procedures; FSMs, and data structures: 


SESSION_LIMIT_DATA_LOCK_MANAGER page 5.4-66 
VERB_PARAMETER_CHECK page 5.4-47 
SOURCE_CONVERSATION_CONTROL page 5.4-48 
CHECK_CNOS_REPLY page 5.4-55 
CHANGE_ACTION page 5.4-43 
PARTNER_LU page A-2 

MODE page A-3 
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SOURCE_SESSION_LIMIT_PROC 


. Call VERB_PARAMETER_CHECK (page 5.4-47), 
with the verb parameters, to verify the syntax of the parameters. 


If all parameters are determined to be correct then 


Call SESSION_LIMIT_DATA_LOCK_MANAGER (page 5.4-66) 
to perform a source-LU lock on the affected (LU,mode) entry or entries 
and prevent simultaneous access by other CNOS transactions. 


Select based on one of the following conditions: 
When the state of the lock is changed from UNLOCKED to 
LOCKED _BY_SOURCE for each affected (LU,mode) entry 


MODE is now locked against any other CNOS transaction. 


Build a CNOS command record with the parameters specified on the verb 
and consistent with the change-number-of-sessions record 
(SNA Formats). 


If the MODE.SESSION_ LIMIT < the new limit that is being proposed then 
Set MODE.CNOS_NEGOTIATION_IN_PROGRESS = TRUE. 
Set MODE.LIMIT_BEING_ NEGOTIATED = LU_MODE_SESSION_LIMIT from verb. 
This is done so BINDs that arrive prior to the CNOS reply are not rejected. 


C If the command is change or initialize session limits then 


Do until the CHECK_CNOS REPLY procedure does not return RETRY 


The verb completes or a permanent error occurs. 


Call SOURCE_CONVERSATION_CONTROL (page 5.4-48), 
C. with the CNOS command, to send on the conversation and to receive the CNOS reply. 
we 


If the SOURCE_CONVERSATION_CONTROL returns OK (a CNOS reply was 
successfully received) then 
Optionally, perform syntax checking on the CNOS reply record 
according to the description in SNA Formats. 


If the CNOS reply is syntactically correct, or the syntax 
check was not performed then 
Call CHECK_CNOS_REPLY with the CNOS reply record and the 
network-qualified LU names for the source and target LUs 
to determine the result of the negotiation (page 5.4-55). 


ee Else 
C Set the CNOS RETURN CODE to RESOURCE_FAILURE_NO_RETRY. 


If the session limits were successfully accepted or negotiated then 


Call CHANGE_ACTION (page 5.4-43), with the CNOS reply, 
to update the limits in the MODE structure for the source LU and notify RM. 


If the command is change or initialize session limits then 
Set MODE.CNOS_NEGOTIATION_IN_PROGRESS = FALSE. 
Call SESSION_LIMIT_DATA_LOCK_MANAGER (page 5.4-66) 
to perform the unlock operation on the affected (LU,mode) entry or entries. 


When the lock operation performed on any of the affected (LU,mode) entries 
was other than a state change from UNLOCKED to LOCKED_BY_SOURCE 
(because of a previous lock operation performed for a different CNOS command ) 
Set the CNOS RETURN_CODE to COMMAND_RACE_REJECT. 


When the mode name is not found for the PARTNER_LU 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
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VERB_PARAMETER_CHECK 


VERB_PARAMETER_. 


FUNCTION: 


CHECK 


This procedure performs validity checks on the CNOS verb issued by ‘the 
control-operator transaction program at the source LU, and it returns the 
CNOS-verb RETURN_CODE for any error detected. 


Parameters from transaction program verb, PARTNER_LU_LIST and MODE_LIST 


CNOS verb RETURN_CODE value if any errors are detected; otherwise, OK is 
returned 


This procedure locks the MODE for the entire procedure. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 

MODE page A-3 
Verify that the specified verb parameters satisfy the parameter values as 2 
described for this verb in SNA Transaction Programmer's Reference Manual for LU Type 6.2. . jms 


Select based 


on result of parameter verification: 
When all parameters are correct 
Set the CNOS RETURN_CODE for this verb to OK--AS_SPECIFIED. 
When a program parameter check condition is identified as described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


When a parameter error is identified 


When the verb issued is INITIALIZE_SESSION_LIMIT and the MODE.SESSION_LIMIT 


Set the CNOS RETURN_CODE to PARAMETER_ERROR. " $3 _: 


is not 0 


for the affected MODE at the PARTNER_LU Sued) 


Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_NOT_ZERO. 
When the verb issued is CHANGE_SESSION_LIMIT and the MODE .SESSION_LIMIT 


is O for 


the affected MODE at the PARTNER_LU 


Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_ZERO. 
When the specified session limit could not be added without exceeding 
the session limit in the LUCB for the LU (page 5.4-4). 
Set the CNOS RETURN_CODE to LU_SESSION_LIMIT_EXCEEDED. 
When the specified session limit could not be added without exceeding 
the LOCAL_MAX_SESSION_LIMIT in the MODE | 


Set the CNOS RETURN_CODE to REQUEST_EXCEEDS MAX_ALLOWED. 


7 
( ) 


5.4-48 SNA LU 6.2 Reference: Peer Protocols 


SOURCE_CONVERSATION_CONTROL 


C SOURCE_CONVERSATION_CONTROL 


FUNCTION: This procedure controls a conversation with the target LU to send the CNOS 
command and receive the CNOS reply. It controls the selection of mode name 
for the conversation. In the event of session outage, it retries the conver- 
sation either until it succeeds or until no sessions are active for any mode 
name affected by the CNOS verb. 


CNOS verb parameters including the name of the target LU; CNOS command; summa- 
ry of the success or failure of the CNOS exchange across the conversation 
(provided by the SOURCE_CONVERSATION procedure) so this routine can make a 


retry decision: 


¢ OK: conversation completed successfully 

° SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 
FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


C OUTPUT: CNOS reply; summary of outcome of conversation for caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_CONVERSATION page 5.4-49 
LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 


Do until the SOURCE_CONVERSATION procedure returns a value 
OK or FAILED, or if all possible modes are tried but no sessions 
are available on any of these 


3 Choose a mode name with which to allocate a conversation. The mode 
a name is optionally selected from an implementation-defined list 
(if any of these sessions is immediately available) or the SNA- 
defined mode name SNASVCMG. 
Choose the RETURN_CONTROL value for the ALLOCATE verb 
(see SNA Transaction Programmer's Reference Manual for LU Type 6.2). 


Initially, choose mode names from the implementation defined list and 
use a RETURN_CONTROL value of IMMEDIATE. Once these have been 
exhausted, try the SNA-defined mode (SNASVCMG) with a RETURN_CONTROL 
value of WHEN_SESSION_ALLOCATED. If this is not successful, choose a 
a mode name from those that will be affected by this CNOS command and 


use a RETURN_CONTROL value of WHEN_SESSION_ALLOCATED. 


Call SOURCE_CONVERSATION (page 5.4-49) with the parameters 
chosen above and the CNOS command record. SOURCE_CONVERSATION will issue 
the basic conversation verbs to send the CNOS command, receive the CNOS 
reply over the conversation and obtain the network-qualified LU names for 
this and the partner LU for later comparison. 


If SON (session outage notification) is returned, the conversation is 


retried on another session for the same mode name. 


Set the return value for this routine to the value. returned from 
SOURCE_CONVERSATION. 
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SOURCE_CONVERSATION 


FUNCTION: 


OUTPUT : 


This procedure conducts a conversation with the target LU to send the CNOS 
command and receive the CNOS reply. It issues the conversation verbs. It 
invokes other routines to analyze the return codes to determine when and how 
to deallocate the conversation and whether retry is necessary. 


LU name of the partner, mode name for the conversation on which the 
CHANGE_NUMBER_OF_SESSIONS command and reply records are exchanged; the 
RETURN_CONTROL parameter for the ALLOCATE verb; CNOS command 


CNOS reply; summary of the success or failure of a particular basic conversa- 
tion verb, according to the particular RESULT_CHECK_* procedure called: 


e OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session 1s available for this mode name; retry for another 
mode name might succeed | 
FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed | 


The SOURCE_CONVERSATION_CONTROL procedure will make a retry decision based on 
this information. 


See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for conver- 


Referenced procedures, FSMs, and data structures: 


RESULT_CHECK_ALLOCATE page 5.4-51 
RESULT_CHECK_SEND_COMMAND page 5.4-52 
RESULT_CHECK_RECEIVE_REPLY page 5.4-53 
RESULT_CHECK_RECEIVE_DEALLOCATE page 5.4-54 


| Conduct a conversation with the partner. 


Issue the ALLOCATE verb according to the mode name and RETURN_CONTROL values 
passed to this procedure and default values as described on page 5.4-27. 

Call RESULT_CHECK_ALLOCATE to examine the RETURN_CODE value from the ALLOCATE | 
(according to the RETURN_CONTROL value specified on the verb) and issue DEALLOCATE 
for the conversation if appropriate (page 5.4-51). | 
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SOURCE_CONVERSATION 


oe If the ALLOCATE verb returned OK then 
| Issue a GET_ATTRIBUTES verb, with the RESOURCE parameter returned 
| from the ALLOCATE, to obtain the network-qualified LU name of 
the partner LU. 
Issue a GET_TP_PROPERTIES verb to get the network-qualified LU name of 
the local LU. 


Issue a SEND_DATA verb to send the CNOS command. 

Call RESULT_CHECK_SEND_COMMAND (page 5.4-52) to examine 
the parameters returned from the SEND_DATA verb and perform the DEALLOCATE 
1f appropriate. 


If the SEND_DATA verb returned OK then 
Issue a RECEIVE_AND_WAIT verb to receive the CNOS reply. 
Call RESULT_CHECK_RECEIVE_REPLY (page 5.4-53) to examine 
the parameters returned from the RECEIVE_AND_WAIT verb and perform the DEALLOCATE 


s if appropriate. 
C. If the RECEIVE AND_WAIT verb returned OK then 
Issue the RECEIVE_AND_WAIT verb to receive the DEALLOCATE from the 
partner LU. 
Call RESULT_CHECK_RECEIVE_DEALLOCATE (page 5.4-54¢) to examine 
the parameters returned from the RECEIVE_AND_WAIT verb and perform the DEALLOCATE 
if appropriate. 


Set the return code for this procedure from the value returned by the last 
RESULT_CHECK_® procedure called. 
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RESULT_CHECK_ALLOCATE 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the ALLOCATE verb that allocates the CNOS conversation, and it clas- 
sifies the outcome for use in later decisions, specifically whether to retry, 
quit, or continue. For some error conditions, the conversation will need to 
be deallocated. 


INPUT: RETURN_CODE, RETURN_CONTROL 


OUTPUT : Summary of the success or failure of the ALLOCATE verb: 


®* OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

® NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 
FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


This information will be used by SOURCE-CONVERSATION_CONTROL to make a retry 
decision. 


Checks are required unless designated optional. 


Select based on the RETURN_CONTROL value specified on the ALLOCATE verb: 
When IMMEDIATE (implementation-selected mode name) 


Select based on the RETURN_CODE value from the ALLOCATE verb: 


When OK 
Return OK to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR (optional check) yan 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate ( , 
the conversation locally. he. of 


Return FAILED to the SOURCE_CONVERSATION procedure. 
When UNSUCCESSFUL (no session is immediately available) 

Return NO_SESSION to the SOURCE_CONVERSATION procedure. 
Otherwise (optional check) 

Return FAILED to the SOURCE_CONVERSATION procedure. 


When WHEN_SESSION_ALLOCATED 


Select based on the RETURN_CODE value from the ALLOCATE verb: 


When OK 

Return OK to the SOURCE_CONVERSATION procedure. | Va 
When ALLOCATION_ERROR--ALLOCATION_FAILURE_RETRY 

Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the a 


cornersation locally. 

Return NO_SESSION to the SOURCE_CONVERSATION procedure. 
Otherwise (optional check) 

Return FAILED to the SOURCE_CONVERSATION procedure. 


5.4-52 SNA LU 6.2 Reference: Peer Protocols 


RESULT_CHECK_SEND_COMMAND 


RESULT_CHECK_SEND_COMMAND 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 


ters from the SEND_DATA verb that sends the CNOS command, and it classifies 
the outcome for use in later decisions, specifically whether to retry, quit, 
or continue. For some error conditions, the conversation may need to be deal- 


located. 


INPUT : RETURN_CODE, REQUEST_TO_SEND_RECEIVED 


OUTPUT: Summary of the success or failure of the SEND_DATA verb: 


e OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 

e FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


This information will later be used by SOURCE_CONVERSATION_ CONTROL to make a 
retry decision. 


Checks are required unless designated optional. 


Select, in order, based on the RETURN_CODE parameter from the SEND_DATA verb: 


When OK 
If the REQUEST_TO_SEND_RECEIVED parameter returned from the SEND_DATA verb is YES then 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Else 
Return OK to the SOURCE_CONVERSATION procedure. 


When RESOURCE_FAILURE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation 
locally. 
Return SON (session outage notification) to the SOURCE_CONVERSATION procedure. 


When ALLOCATION_ERROR--SECURITY_NOT_VALID, 
ALLOCATION_ERROR--TP_NOT_AVAILABLE_NO_RETRY, 
or ALLOCATION _ERROR--TP_NOT_AVAILABLE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally 
Return FAILED to he SOURCE _CONVERSATION procedure. 
When ALLOCATION_ERROR--* (optionally check for any other wee of ALLOCATION_ERROR) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


When DEALLOCATE_ABEND_PROG 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation 
locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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RESULT_CHECK_RECEIVE_REPLY 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives the CNOS reply, and it clas- 
sifies the outcome for use in later decisions, specifically whether to retry, 
quit, or continue. For some error conditions, the conversation may need to be 
deal located. 


INPUT : RETURN_CODE, REQUEST_TO_SENT_RECEIVED, WHAT_RECEIVED 


OUTPUT: Summary of the success or failure of the RECEIVE_AND_WAIT verb: 


e OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 
FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


This information will later be used by SOURCE_CONVERSATION_CONTROL to make a 
retry decision. 


Checks are required unless designated optional. 


Select based on the RETURN_CODE value returned from the RECEIVE_AND_WAIT verb: 
When OK 
If the WHAT_RECEIVED parameter returned is DATA_COMPLETE then 
If the REQUEST_TO_SEND_RECEIVED parameter from the RECEIVE_AND_WAIT verb is NO then 
Return OK to the SOURCE_CONVERSATION procedure. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. C > 
Else | 


Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
When RESOURCE_FAILURE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return SON (session outage notification) to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR--SECURITY_NOT_VALID, ALLOCATION_ERROR--TP_NOT_AVAILABLE_NO_RETRY >, 
or ALLOCATION _ERROR--TP_NOT_AVAILABLE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
- Return FAILED to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR--* oa 
(optionally check for any other variety of ALLOCATION_ERROR) \ 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. meee 
Return FAILED to the SOURCE_CONVERSATION procedure. 
When DEALLOCATE_NORMAL or DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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RESULT_CHECK_RECEIVE_DEALLOCATE 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives DEALLOCATE from the target 
LU, and it classifies the outcome for use in later decisions, specifically 
whether to retry, quit, or continue. For some error conditions, the conversa- 
tion may need to be deallocated. 


INPUT: RETURN_CODE, REQUEST_TO_SEND_RECEIVED, WHAT_RECEIVED (used only for error log) 


OUTPUT: Summary of the success or failure of the RECEIVE_AND_WAIT verb: 


e¢ OK: conversation completed successfully 

e SON: session outage occurred; retry on the same mode name might succeed 

¢ NO_SESSION: no session is available for this mode name; retry on another 
mode name might succeed 


FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


Select based on the RETURN_CODE value returned from the DEALLOCATE verb: 
When DEALLOCATE_NORMAL 
If the REQUEST_TO_SEND_RECEIVED parameter from RECEIVE _AND_WAIT verb is YES then 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Else 


Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
Return OK to the SOURCE_CONVERSATION procedure. 


When RESOURCE_FAILURE_RETRY 


ee Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
/ Return SON (session outage notification) to the SOURCE_CONVERSATION procedure. 


When DEALLOCATE_ABEND_PROG 


Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


Otherwise 


Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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CHECK_CNOS_REPLY 


FUNCTION: This procedure is_ called when the conversation with the target LU completes. 
It determines whether the conversation must be retried due to a double-failure 
race condition, whether the verb must be terminated due to error, or whether 
to continue with the action phase of CNOS processing. 


It performs optional receive checks on the validity of the reply. It sets the 
return code for the CNOS verb. 


Fields of the CNOS reply record, PARTNER_LU_LIST and MODE_LIST for current 
session limit OUTPUT.CNOS RETURN_CODE, if any errors are found; RETRY, used by 
caller to select subsequent processing 


Checks are required unless designated optional. 


Referenced procedures, FSMs, and data structures: 
LUCB page A-l 
PARTNER_LU page A-2 


Select based on the reply modifier field of the CNOS reply record: 
When the reply modifier 1s MODE_NAME_NOT_RECOGNIZED 
Set the CNOS RETURN_CODE to UNRECOGNIZED _MODE_NAME. 
When the reply modifier indicates an (LU,mode) session limit of 0 
Verify that, for the PARTNER_LU MODEs specified on the original CNOS verb, 
that the SESSION _LIMIT=0, and DRAIN_SELF=NO. 


If these MODE attributes are correctly verified then 
Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_CLOSED. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. fo ™ 
When the reply modifier is COMMAND _RACE_DETECTED Lo 
Check the state of the lock to determine whether the race is a single- or Sa 


double-failure race (page 5.4-30). 

Compare the network-qualified LU names for the source and target LUs 
(returned from the GET_ATTRIBUTES and GET_TP_PROPERTIES verbs in the 
SOURCE_CONVERSATION procedure) with respect to the EBCDIC collating sequence 
(page 5.4-14). 


If the race detected is a single-failure race or the LU name of the target 
LU is greater by the above comparison then 
Set the CNOS RETURN_CODE to COMMAND_RACE_REJECT. 


Else (double-failure race condition and source LU name is greater) yess 
Return RETRY to SOURCE_SESSION_LIMIT_PROC. 3 ( 
When the reply modifier is ACCEPTED Nw 


Set the CNOS RETURN_CODE to OK--AS_SPECIFIED. 
When the reply modifier 1s NEGOTIATED 
Optionally verify that the parameters in the CNOS reply were correctly 
negotiated, according to page 5.4-28. 


If the reply parameters were successfully verified or the optional 
checks were not implemented then 
Set the CNOS RETURN_CODE to OK--AS_NEGOTIATED. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 


Ne 
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FUNCTION: This procedure is the CNOS service transaction program at the target LU. It 
is invoked by PS_INITIALIZE as a result of an FMH-5 Attach header being 
received from the source LU. It issues the PROCESS SESSION_LIMIT control 
operator verb to activate CNOS processing at the target LU. It informs the 


target-LU operator of the CNOS action. 


OUTPUT: Issues control-operator verb PROCESS SESSION_LIMIT 


ois NOTE: See SNA _ Transaction Programmer's Reference Manual for LU Type 6.2 for 
E. control-operator verbs. 


Issue the PROCESS SESSION_LIMIT verb to be processed by PS_COPR 
(page 5.4-32) and inform the target-LU operator of the 
resulting CNOS RETURN_CODE. 


The algorithm to inform the operator is implementation dependent. 
This algorithm may make use of DEFINE or DISPLAY control-operator 


verbs to determine the current session limits, in the MODE, and then 
4 display them on the operator console. 


C_ 
‘\ 
' 
7 
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PROCESS _SESSION_LIMIT_PROC 


FUNCTION: This procedure is invoked by PS_COPR, the control-operator-verb router, when 
the CNOS service transaction program at the target LU issues a PROC- 
ESS_SESSION_LIMIT control-operator verb. This procedure directs overall proc- 
essing of CHANGE_NUMBER_OF_SESSIONS at the target LU. This procedure receives 
the CNOS command from the source LU and sends the CNOS reply. It invokes TAR- 
GET_CONVERSATION to issue the conversation verbs and process the return codes. 


It invokes other procedures to check the verb and the conversation attributes 
for validity, detect and resolve race conditions with any other CNOS trans- 
action, negotiate CNOS parameters, update the affected MODEs with the new ses- 
sion limit parameters, and, if necessary, request the resources manager to 
activate or deactivate sessions. If errors are detected at any point, it 
skips subsequent steps and cleans up’ from previous’ steps. It passes a 
RETURN_CODE to the calling procedure in the PROCESS _SESSION_LIMIT record indi- 
cating success or a failure reason. 


INPUT: PROCESS SESSION_LIMIT verb, CNOS command from the source LU via the conversa- 
tion; PARTNER_LU_LIST and MODE_LIST 


OUTPUT: Outcome of the operation to the caller in PROCESS _SESSION_LIMIT (RETURN_CODE ); 
CNOS reply sent to the source LU via the conversation; updated MODE entries 
via CHANGE_ACTION; CHANGE_SESSIONS record to RM, via CHANGE_ACTION; SES- 
SION_LIMIT_DATA lock tested, set, and reset via SES- 
SION_LIMIT_DATA_LOCK_MANAGER 


Referenced procedures, FSMs» and data structures: 


NEGOTIATE_REPLY page 5.4-63 
CHECK_CNOS_COMMAND page 5.4-62 
CHANGE_ACTION page 5.4-43 
TARGET_COMMAND_CONVERSATION page 5.4%-60 
TARGET_REPLY_CONVERSATION page 5.4-64 
SESSION_LIMIT_DATA_LOCK_MANAGER page 5.4-66 
LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 
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PROCESS_SESSION_LIMIT_PROC 


Check the verb parameters to detect ABEND conditions as described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2 for this verb. 
If either of the ABEND conditions exists then 

Set the CNOS RETURN_CODE to PROGRAM_PARAMETER_CHECK. 


Else 
Call TARGET_COMMAND CONVERSATION (page 5.4-60) 
with the resource ID of the conversation with the partner LU to receive 
the CNOS command from the source LU. 
If an error occurs before the CNOS command can be successfully received then 
Set the CNOS RETURN CODE to RESOURCE _FAILURE_NO RETRY. 


Else 
Call SESSION_LIMIT_DATA_LOCK_MANAGER to perform a target-LU lock 
on the appropriate (LU,mode) entry or entries to prevent 
simultaneous access by other CNOS transactions (page 5.4-66). 
Optionally, perform syntax checking on the CNOS command record according 
to the description in SNA Formats. 


Select, in order, based on the values of fields in the CNOS command: 
When syntax errors are identified 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
When the MODEs specified on the CNOS command cannot be found 
in the list of MODEs for the PARTNER_LU 
Set the reply modifier field for the CNOS reply to MODE_NAME_NOT_RECOGNIZED. 
When the MODEs specified on the CNOS command have SESSION_LIMIT=0, and 
DRAIN_SELF=NO then 
The LU may refuse to accept the command by returning an abnormal reply 
modifier field specifying an (LU,mode) session limit of 0 
(this is implementation defined). 
Otherwise 


Select based on result of SESSION_LIMIT_DATA_LOCK_MANAGER: 
When the state of the LOCKs have changed from UNLOCKED 
to LOCKED_BY_TARGET 
Call CHECK_CNOS_COMMAND (page 5.4-62), with the CNOS command; 
to perform optional receive checks (if errors are found, 
the conversation is deallocated). | 
If the checks were not performed or no errors were detected then 
Call NEGOTIATE_REPLY (page 5.4-63), with the CNOS command 
record, in order to generate the negotiated values of the 
CNOS parameters. 
Otherwise (1f any LOCK has been rejected) 
Set the reply modifier field for the CNOS reply to COMMAND_RACE_DETECTED. 


If the conversation has not been deallocated then | 
Build the CNOS reply record consistent with the original CNOS command, the reply modifier 
field reflecting the identified errors, and the negotiated CNOS limits, as 
appropriate (see SNA Formats). 


If the command is change or initialize session limits then 
If the modifier field of the CNOS reply is accepted or negotiated then 
If the new limit > MODE.SESSION_LIMIT then 
Set MODE .CNOS_NEGOTIATION_IN_PROGRESS to TRUE. 
Set MODE.LIMIT_BEING_NEGOTIATED to LU_MODE_SESSION_LIMIT. 


Call TARGET_REPLY_CONVERSATION (page 5.4-64) 
with the CNOS reply record to be sent to the source LU. 


If the CNOS reply is successfully sent across the conversation then 
Set the CNOS RETURN_CODE for the PROCESS SESSION_LIMIT verb according 
to the modifier field of the CNOS reply. 
If the reply modifier field indicates that the CNOS limits were either ACCEPTED 
or NEGOTIATED then 
Call CHANGE_ACTION (page 5.4-43) with the CNOS reply record 
to change the session limits at the target LU. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
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If the command is change or initialize session limits then 
Set MODE.CNOS_NEGOTIATION_IN_PROGRESS to FALSE. 


Call SESSION_LIMIT_DATA_LOCK MANAGER (page 5.4-66) to UNLOCK the affected 
(LU,mode) entry or entries. 
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TARGET_COMMAND_CONVERSATION 


FUNCTION: This procedure checks the attaching conversation for validity and returns the 
partner LU name to the caller. If the conversation is’ valid, this procedure 
receives the CNOS command from the source LU. If an error is detected, it 
terminates the conversation with DEALLOCATE TYPE( ABEND_PROG). 


INPUT : 


OUTPUT: 


NOTE : 


Resource ID of the conversation with the partner (source) LU, conversation 
attributes via GET_ATTRIBUTES 


Partner LU name, from conversation via GET_ATTRIBUTES; CNOS command, from the 
source LU via the conversation; 


sation verbs. 


Referenced procedures, FSMs, and data structures: 


RESULT_CHECK_RECEIVE_COMMAND page 5.4-61 
RESULT_CHECK_RECEIVE_SEND page 5.4-61 


Issue a GET_TYPE verb (according to the input parameters provided) to verify that the 
type of conversation is BASIC. 

Issue a GET_ATTRIBUTES verb (according to the input parameters provided) to verify 
that the connection type is parallel sessions and that the SYNC_LEVEL 
is NONE (optional receive check). 


The GET_ATTRIBUTES verb returns the name of the source LU. The target then uses 


this information to determine the type of sessions possible with the source LU as 
a conversation partner. 


If the above conversation attributes are not verified to be correct then 
(optional check ) 

Issue a DEALLOCATE verb with TYPE=ABEND_PROG and return from this procedure. 
The LOG_DATA parameter of the DEALLOCATE verb, if used, is supplied by the 
implementation. For its format, see ERROR LOG GDS VARIABLE in 
SNA Formats. 


Else 


Issue a RECEIVE_AND_WAIT verb to receive the CNOS command. 
Call RESULT_CHECK_RECEIVE_COMMAND to examine the parameters returned and perform 
the DEALLOCATE, if appropriate (page 5.4-61). 


If RESULT_CHECK_RECEIVE_COMMAND returns OK then 
Issue a RECEIVE_AND_WAIT verb to receive the SEND indicator. 
Call RESULT_CHECK_RECEIVE_SEND to examine the parameters returned and perform 


the DEALLOCATE, if appropriate (page 5.4-61). If RESULT CHECK _RECEIVE_SEND 
returns OK, the CNOS command was successfully received. 
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RESULT_CHECK_RECEIVE_COMMAND 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives the CNOS command; it deter- 
mines whether to issue DEALLOCATE, and what TYPE to specify. 


RETURN_CODE, REQUEST_TO_SEND_RECEIVED, WHAT_RECEIVED 


Checks are required unless designated optional. 


Select based on the RETURN_CODE parameter returned from RECEIVE_AND WAIT: 
When OK 
If WHAT_RECEIVED = DATA_COMPLETE then 
If the REQUEST_TO_SEND_RECEIVED parameter from the RECEIVE_AND_WAIT 
verb is YES then 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Else 
Return OK to TARGET_COMMAND_CONVERSATION. 
Else (optional check) oe 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
When RESOURCE_FAILURE_RETRY, DEALLOCATE_NORMAL or DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
When RESOURCE FAILURE _NO_RETRY : 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Otherwise (optional check) 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 


- 
y 


RESULT_CHECK_RECEIVE_SEND 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives SEND; it determines whether 
to issue DEALLOCATE, and what TYPE to specify. 


RETURN_CODE, REQUEST_TO_SEND_ RECEIVED, WHAT_RECEIVED 


Checks are required unless designated optional. 


Select based on the RETURN_CODE parameter returned from the RECEIVE_AND_WAIT: 
When OK 
If WHAT_RECEIVED = SEND & REQUEST_TO_SEND_RECEIVED = NO then 
Return OK to TARGET_COMMAND_CONVERSATION. 
Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
When RESOURCE_FAILURE_RETRY, DEALLOCATE_NORMAL, or 
DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
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FUNCTION: This procedure performs receive checks at the target LU on the CNOS command 


received from the source LU. If errors are detected, DEALLOCATE ABEND 
replaces a CNOS reply. 


CNOS command parameters 


Checks are required unless designated optional. 


. Referenced procedures, FSMs» and data structures: 
| MODE page A-3 
Optionally check the verb parameters, encoded as fields in the 

CNOS command, for ABEND conditions as described in 


| 
C . Since the session limits of the SNA-defined mode name, SNASVCMG, may 
oa not be changed» a mode name of SNASVCMG in the CNOS' command consti- 
tutes another ABEND condition. 


Some parameter checks may require Knowledge of mode attributes that 
currently exist. For these, see the appropriate MODE structure for 
the specified PARTNER_LU. 


If any ABEND condition is identified then 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG 
* to deallocate the conversation. 
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NEGOTIATE_REPLY 


FUNCTION: This procedure generates the negotiated values of the CNOS limits for the CNOS_ 


reply, including the reply modifier field. 


This procedure assumes that the session limit parameters in the command are 
valid. 


INPUT: Source-LU specified CNOS verb parameters, PARTNER_LU_LIST, and MODE_LIST 


OUTPUT: Session limit parameters for reply 


NOTE : This procedure does not change the CNOS limits in the MODE. 


Referenced procedures, FSMs», and data structures: 


CLOSE_ONE_REPLY page 5.4-64 
PARTNER_LU | page A-2 
MODE | , page A-3 


If the CNOS verb issued at the source LU is INITIALIZE_SESSION_LIMIT 

or CHANGE_SESSION_LIMIT (when the action field of the CNOS command is SET) then 
Negotiate the LU _MODE_SESSION_ LIMIT» MIN_CONWINNERS SOURCE » 
and MIN_CONWINNERS_TARGET parameters (as described in 


If any of the session limits are going to be less than the current 
limits, RESPONSIBLE may also be negotiated from TARGET to SOURCE. 


Else (RESET_SESSION_LIMIT verb) 
If the command affects only one MODE at the PARTNER_LU then 
Call CLOSE_ONE_REPLY (page 5.4-6¢) 
with the CNOS command record to build the CNOS reply record. 
Else (all mode names affected, and only RESPONSIBLE may be negotiated) 
If RESPONSIBLE is target then 
If RESPONSIBLE parameter is negotiated for this LU then 
Negotiate the RESPONSIBLE parameter from TARGET to SOURCE. 
Set the reply modifier field of the CNOS reply to NEGOTIATED. 
Else 
Set the reply modifier field of the CNOS reply to ACCEPTED. 
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CLOSE_ONE_REPLY 


CLOSE_ONE_REPLY 


FUNCTION: This procedure builds the target-LU's reply whenever the verb issued at the 
source LU is RESET_SESSION_LIMIT (action field of the CNOS command is CLOSE) 
and only one mode name is affected. It optionally sets the reply-modifier 
field of the CNOS reply to MODE_NAME_CLOSED if there is an error in 
DRAIN_SOURCE. 


INPUT: LU_NAME of partner LU; MODE, for current state of CNOS parameters; CNOS com- 
mand parameters 


OUTPUT: Updated_reply modifier and negotiated parameters 


Referenced procedures, FSMs, and data structures: 
MODE page A-3 


Create the CNOS reply according to the negotiation rules described on 
page 5.4-28 (when the action field in the CNOS command 

is CLOSE and only one mode name is affected) and the description of 

the DRAIN and RESPONSIBLE parameters of the RESET_SESSION_LIMITS verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


If the current session limit is 0, the drain for the source’ LU 
(MODE.DRAIN_PARTNER) is set to NO and the - command specifies 
DRAIN_SOURCE(YES), the target LU may either issue a DEALLOCATE with 
TYPE=ABEND or send a CNOS reply with the MODIFIER field spoon e209 an 
(LU,mode) session limit of 0. 


This condition occurs only when there is a design error in the source 
LU such that this ABEND condition is not recognized and the command is 
forwarded to the target LU. 


TARGET_REPLY_CONVERSATION 


FUNCTION: This procedure sends the CNOS reply. 


INPUT: Resource ID of the conversation with the partner (source) LU; the 
change-number-of-sessions record, in this case, a CNOS reply 


OUTPUT: Outcome of conversation (reply and DEALLOCATE NORMAL sent; DEALLOCATE ABEND 
-sent or DEALLOCATE received) 


NOTE : See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for conver- 
sation verbs. 


Referenced procedures, FSMs, and data structures: 
RESULT_CHECK_SEND_REPLY page 5.4-65 


Issue a SEND_DATA verb (with the resource ID of the attaching conversation) 
to send the CNOS reply to the source LU. 


Call RESULT_CHECK_SEND_REPLY (page 5.4-65) to examine 


the parameters returned on the verb and perform a DEALLOCATE of the conversation, 
1f appropriate. 
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RESULT_CHECK_SEND_REPLY 


RESULT_CHECK_SEND_REPLY 


This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the SEND_DATA verb that sends the CNOS reply, and it determines 
whether to issue DEALLOCATE, and what TYPE to specify. 


RETURN_CODE , REQUEST_TO_SEND_RECEIVED 


Select based on the RETURN_CODE parameter returned from the SEND_DATA verb: 
When OK : . 
If the REQUEST_TO_SEND_RECEIVED parameter from the SEND_DATA verb is NO then 
Issue a DEALLOCATE verb with TYPE=SYNC_LEVEL to deallocate the conversation normally. 
Else oe | 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
When RESOURCE_FAILURE_RETRY, RESOURCE_FAILURE_NO_RETRY, DEALLOCATE_ABEND_PROG, 
DEALLOCATE_NORMAL, DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. — 
Otherwise < 


Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
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SESSION_LIMIT_DATA_LOCK_MANAGER 
SESSION_LIMIT_DATA_LOCK_MANAGER 


FUNCTION: This procedure determines whether the specified MODEs exist, and if so, sets 
or resets the session-limit-data lock in the MODE entry to prevent simultane- 
ous access by another CNOS transaction initiated at this or the partner LU. 


The operation to be performed, identification of whether source or target LU 
issued the request, partner LU name and mode name, PARTNER_LU_LIST, and 
MODE_LIST 

OUTPUT: The state of the lock in affected MODE entries is updated 


NOTE : This procedure locks the MODE. 


Referenced procedures, FSMs» and data structures: 


LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 
C - Select based on the requested locking operation: 
ae When LOCK 


Change the state of the lock (or locks) as described on page 5.4-30. 


The four resulting lock states depend upon their previous lock 

state (if applicable) and the input that caused the transition to that state. 
For any input operation and current lock state combination not explicitly 
described, the state of the lock does not change. 


If the CNOS command affects all MODEs for the PARTNER_LU 

then the lock is to be placed on all affected (LU,mode) entries. 

If any of the affected (LU,mode) entries has been previously 
LOCKED_BY_SOURCE, LOCK_DENIED is set for that mode name, 
C } but the others are left unlocked. | 
a When UNLOCK 

The state of the (LU,mode)-entry lock can be changed to the UNLOCK state 
only when the UNLOCK is attempted by the transaction program at the LU 
that currently has the entry locked. 


sore 
N 


Note that, in the LOCK_DENIED state, the transaction program at the 
source LU has the lock on the (LU,mode) entry. 


If the CNOS command affects ALL MODEs, the UNLOCK is performed for all 
affected (LU,mode) entries. 


é 
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GENERAL DESCRIPTION 
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Figure 6.0-l1. Overview of Half-Session 


The half-session component (see Figure 6.0-1) 
resides in the LU and represents a session 
with another LU, which is an LU-LU session. 
The half-session's primary function is to 
control the data traffic flow for a session. 
It also performs initialization when acti- 
vated and, when necessary, causes itself to 
be deactivated. 


The components of the half-session are an 
initializer, a router, data flow control 
(DFC--see “Chapter 6.1. Data Flow Control"), 
and transmission control (TC--see "Chapter 
6.2. Transmission Control"). The initializer 
records information from the session acti- 
vation request (e.g., BIND) for later use by 
DFC and TC. The router distributes message 
units to DFC and TC. A record received from 
the LU session manager (SM--see “Chapter 4. 


) LU Session Manager"), and message units 


oA, 
s 
a 


received from the LU resources manager 
(RM--see "Chapter 3. LU Resources Manager") 
and from presentation services (PS--see 
“Chapter 5.0. Overview of Presentation Serv- 


Presentation 
Services Buf fer 
(PS) Manager 
A (BM) 


Half-session (HS) 


ices") are routed to DFC. Message units 
received from path control (PC) are routed to 
Tc. The primary functions of DFC are to 
translate between basic information units 
(BIUs) and records produced from transaction 
program verbs, and to control the flow of 
data between the half-session (HS) and PS, 
RM, and the buffer manager (BM). The primary 
function of TC is to control the flow of data 
between the half-session and path control. 


The LU half-session is created by SM when a 
session-activation request (e.g., BIND) has 
been success fully processed. The 
half-session is destroyed by SM when (1) a 
session-deactivation RU(-RSP(BIND) or UNBIND) 
has been processed, or (2) a session route 
outage has occurred. 


The half-session, RM, PS, SM, and PC are all 
separate processes. Message units are sent 
to HS by RM, PS, and PC. When a message unit 
arrives, HS may receive and process it. 
Another message unit cannot be received by HS 
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until the current one is completely proc- 
essed. 


HS can selectively receive from these proc- 
esses; e.g.» when HS is waiting for a 
required reply or response from the partner 
HS, HS may elect to ignore messages from PS 
and process messages from only RM, SM, BM, 
and PC. 


e ADJUST_BUF_POOL (from HS to BM) - to 
change buffer pool size 


¢ BUFFERS _RESERVED 
notify the buffer owner about the buffer 
allocation change 


With each call from HS to the BM, appropriate 
parameters are also passed. The buffer man- 


(from BM to HS) - to 


ager (BM) sends a BUFFERS_RESERVED signal to 
The protocol boundary between HS and BM is: HS, which contains the identifier of the 
buffer assigned. Upon receiving the signal 
from BM, transmission control updates the 
appropriate pacing counts and builds’ and 
sends the appropriate session-level pacing 
response (IPR or IPM). See Appendix B for 
more details on buffer manager function and 
services. 


e GET_BUFFER (from HS to BM) - to 


obtain buffer 
e FREE_BUFFER (from HS to BM) - to 
release buffer 


PROTOCOL BOUNDARIES BETWEEN HS AND OTHER COMPONENTS (— 


Following is a list of the message units that 
flow between HS and other components. 


Message units that flow from HS to RM: Message units that flow from RM to HS: 
FM_HEADER (Attach or Security) BID_WITHOUT_ATTACH 
BID RM_HS_CONNECTED 
BID_RSP BRACKET_FREED 
FREE_SESSION BID_RSP 
BIS RQ YIELD_SESSION 
BIS_REPLY BIS_RQ 
RTR_RQ BIS REPLY 
RTR_RSP RTR_RQ 

RTR_RSP 
HS_PS_CONNECTED 
ENCIPHERED_RD2 


units that flow from PS to HS: 
CONFIRMED 

SEND_ERROR 

REQUEST_TO_SEND 
SEND_DATA_RECORD 


Message units that flow from HS to PS: 
CONFIRMED 
RECEIVE ERROR 
REQUEST_TO_SEND 
RSP_TO_REQUEST_TO_SEND 


Message units that flow from HS to SM: 
INIT_HS_RSP 
ABEND_NOTIFICATION 
ABORT_HS 


Message units that flow from SM to HS: 
INIT_HS 


units that flow from PC to HS: 
MU information containing session 
information to the appropriate HS. 


Message units that flow from HS to PC: 
MU information containing session data to 
PC for transmission. The MU also 
contains the LFSID and the transmission 
priority. 
Message units (modeled in this book as Message units that flow from BM to HS: 
parameters in Call invocations) that flow 
from HS to BM: 
GET_BUFFER signal 
FREE_BUFFER signal 
ADJUST_BUF_POOL signal 


BUFFERS_RESERVED signal 


Figure 6.0-2. Message Units Exchanged Between HS And Other Components. 
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HS 


FUNCTION: This procedure causes the half-session to be initialized and invokes’ the 
half-session router. On completion the HS process is destroyed. 


INPUT: At creation time, HS_CREATE_PARMS containing HS_ID (half-session identifier ) 
and LU_ID (LU identifier); at run time, INIT_HS received from SM 
OUTPUT: INIT_HS_RSP sent to SM, HS_ID and LU_ID recorded for other procedures in the 
half-session. The half-session role (primary or secondary) is recorded from 
C | HS_CREATE_PARMS for use by other procedures in the half-session 
Referenced procedures, FSMs, and data structures: 
SM page 4-48 
RM page 3-19 
TC. INITIALIZE page 6.2-13 
DFC_INITIALIZE : | page 6.1-19 
PROCESS_LU_LU_SESSION page 6.0-5 
HS_CREATE_PARMS page A-26 
INIT_HS page A-13 
INIT_HS_RSP page A-10 
RM_HS_CONNECTED page A-18 
~~, LOCAL page 6.0-7 
‘ Record the HS_ID and LU_ID in the LOCAL data structure to make the 
J information available to all half-session procedures. 


From INIT_HS.TYPE, record an indication that this half-session is 

primary (PRI) or secondary (SEC). 

Set LOCAL.SENSE_CODE to 0 (the no-error state). 

From INIT_HS; record PERMANENT_BUFFER_POOL_ID in the LOCAL data structure. 


Call TC.INITIALIZE( INIT_HS record) (page 6.2-13). 
Call DFC_INITIALIZE(INIT_HS record) (page 6.1-19). 


Initialize INIT_HS_RSP with LOCAL.SENSE_CODE and LOCAL.HS_ID. 


| If LOCAL.SENSE_CODE is O indicating that TC and DFC 
zy initialization were successful then 
Set the TYPE field of INIT_HS_RSP to POS and send the record to SM. 
Receive RM_HS_ CONNECTED from RM. 
Call PROCESS _LU_LU SESSION( page 6.0-5). 
Else (initialization unsuccessful--LOCAL.SENSE_ CODE indicates the type of error) 
Set the TYPE field of INIT_HS_RSP to NEG and send the record to SM. 


Wait for the half-session to be destroyed. 
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HS 


6.0-4 


SM 
ABEND_NOTIFICATION 


Create and initialize an ABEND_NOTIFICATION record indicating HS abended. — 
Send the ABEND_NOTIFICATION record to SM. 
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During the processing in this chapter, 
may be encountered. 
detectable errors 

condition may be detected: 


e There is no buffer (permanent and demand) available to allow HS to 
send session data 


Peer Protocols 


a number of error conditions 
The following logic executes only if one of the 


listed have been following error 


a. 


~— 
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PROCESS_LU_LU_SESSION 


PROCESS_LU_LU_SESSION 


FUNCTION: Does processing for half-session (FM profile 19). Message units received from 


RM and PS are routed to DFC. Message units received from PC are routed to TC. 
The half-session continues to operate until an error condition occurs or the 
half-session process is destroyed. If an error condition occurs, 
LOCAL.SENSE_CODE is set (by DFC or TC) with the sense data indicating what 
kind of error occurred. When this field is set, the half-session sends an 
ABORT message to SM. This causes SM to send an UNBIND(protocol error) for 
this session. HS receives BUFFERS_RESERVED signals from buffer manager (BM) 


and builds and sends the appropriate pacing response. 


OUTPUT : ABORT_HS sent to SM if an error has been detected 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_FROM_RM page 6.1-21 
DFC_SEND_FROM_PS page 6.1-20 
TRY_TO_RCV_SIGNAL page 6.1-23 
TC.RCV page 6.2-23 
BUFFERS _RESERVED_PROCESSING page 6.2-31 
FSM_BSM_FMP19 page 6.1-50 
FSM_CHAIN_SEND_FMP19 page 6.1-53 
ABORT_HS page A-9 

LOCAL page 6.0-7 


Do the following checks while no error has been detected. 


Wait for a record to be received on PS_TO_HS_Q, RM_TO_HS_Q, PC_TO_HS_Q or BM_TO_HS_Q@. 
Check for a record on the PS_TO_HS_Q: 
If the PS_TO_HS _Q contains a record then 
If the session is not between brackets( FSM_BSM_FMP19 * BETB) or 
half-session is not expecting a response( FSM_CHAIN_SEND_FMP19 # PEND_RSP) or 
half-session is not expecting a reply( FSM_CHAIN_SEND_FMP19 * PEND_RCV_REPLY) then 
Remove the first entry from the PS_TO_HS_Q. 
Call DFC_SEND_FROM_PS(record from PS) (page 6.1-20) to route 
the record to DFC. 
Else 
Wait for a record to be received on the RM_TO_HS_Q, PC_ TO_ HS Q, 
or BM_TO_HS_Q. 


Check for a record on the RM_TO_HS Q: 
If the RM_TO_HS_Q contains a record and no errors have been found then 
Receive the record from the RM_TO_HS Q. 
Call DFC_SEND_FROM_RM( record from RM) (page 6.1-21) 
to route the record to DFC. 


Check for a record on the PC_TO_HS_Q: 
If the PC_TO_HS Q contains a record and no errors have been found then 
Receive the record from the PC_TO_HS Q. 
Call TC.RCV( record from PC) (page 6.2-23) 
to route the record to TC. 
(The input to those procedures is the received record. ) 


Call TRY_TO_RCV_SIGNAL (page 6.1-23) to - 

try to process a queued SIGNAL request. Whether or not a queued SIGNAL 
request is processed depends on the state of the half-session. 

The state of the half-session may change each time a record is 

received and processed; therefore, the TRY_TO_RCV_SIGNAL 

procedure is called after each record is received so that it can check 
the current half-session state and process a SIGNAL request if necessary. 


Check for a record on the BM_TO_HS Q: 
If the BM_TO_HS_Q contains a Signal and no errors have been found then 
Receive the signal from the BM_TO_HS Q@. 
Call BUFFERS_RESERVED _PROCESSING( signal from BM, LOCAL. COMMON_CB ) 
(page 6.2-31). 
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INPUT: Message units received from PS, RM, BM, and PC; and LOCAL.SENSE_CODE may be 
set 


6.0-5 


PROCESS_LU_LU_SESSION 


When LOCAL.SENSE_CODE is not 0 (error found) then | 
Send an ABORT_HS record to SM. (The ABORT_HS.SENSE_CODE comes from 
LOCAL .SENSE_CODE; ABORT_HS.HS_ID is the HS_ID saved during HS initialization. ) 
(SM sends an UNBIND. ) 
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DATA STRUCTURES 


LOCAL 


This is the definition of the process data used by the half-session. This data 
accessed by any procedure in the half-session process. 


LOCAL 

COMMON: fields shared by all HS components 
HS ID: ID of this HS 
LU ID: the LU for this HS 
HALF_SESSION: possible values: PRI, SEC 
SENSE_CODE: contains all 0's, if no error was detected; otherwise, 
contains a nonzero sense data value 
PERMANENT_BUFFER_POOL_ID: ID of the permanent buffer pool shared by all HSs 
within an LU 
RQ CODE: possible values: CRV, BIS, LUSTAT;, RTR» SIG, OTHER 


DFC: fields used only by DFC 

LULU: fields used for LU-LU sessions (FM profile 19) 
PS ID: ID of the PS associated with this HS 
BRACKET_ID: ID of the current bracket 
FIRST_SPEAKER: possible values: YES», NO 
DIRECTION: possible values: HS_SEND, HS_RECEIVE 
CT_RCV: contains correlation tables (see page 6.0-8) 
CT_SEND: contains correlation tables (see page 6.0-8) 
SQN_SEND_CNT: contains SNF (see page A-33) 
PHS BB_REGISTER: contains SNF (see page A-33) 
SHS_BB_REGISTER: contains SNF (see page A-33) 
CURRENT_BRACKET_SQN: contains SNF (see page A-33) 
RQD_REQUIRED_ON_CEB: possible values: YES» NO 
NORMAL_FLOW_RQ_COUNT: the number of normal-flow requests sent by 
this HS 
SIG_RECEIVED: possible values: YES, NO 
SIG_SNF: contains SNF (see page A-33) 
BETC: possible values: YES, NO 
SEND_ERROR_RSP_STATE: indicates if a SEND ERROR negative response is owed}; 
possible values: RESET, NEG_OWED 
BB_RSP_STATE: indicates if a BB response is owed; 
possible values: RESET, POS_OWED, NEG_OWED 
BB_RSP_SENSE: contains the sense data carried in a BB response, 
this field is valid only when BB_RSP_STATE=NEG_OWED 
RTR_RSP_STATE: indicates if a RTR response is owed; 
possible values: RESET, POS_OWED, NEG_OWED 
RTR_RSP_SENSE: contains the sense data carried in a RTR response, 

this field is valid only when RTR_RSP_STATE=NEG_OWED 

SIG_RQ OUTSTANDING: possible values: YES, NO 
ALTERNATE_CODE: possible values: WILL_NOT_BE_USED, MAY_BE_USED 
SESSION_JUST_STARTED: possible values: YES, NO 


SAVED_MU_PTR: pointer to the MU containing the RH and two bytes of RU data from 


the received RU 
TC: fields used only by TC 
TCCB: transmission control control block 


MAX_RCV_RU_SIZE: the maximum RU size that can be received by this half-session 


SQN_RCV_CNT: the number of normal-flow requests received by 

this half-session 
COMMON_CB: contains the common control block for session-level 

pacing (see page 6.0-8) 
SEGMENTING_SUPPORTED: the flag used to indicate BIU segmenting support 
CRYPTOGRAPHY: possible values: YES, NO 
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CT 
Correlation table (CT) defines the send/receive RU operation. CT is contained 
half-session process data (LOCAL). 
CT: fields used by DFC 
ENTRY_PRESENT: possible values: YES, NO 
SNF: contains the SNF of the latest RU received or sent for this chain 
(see page A-33) 
NEG _RSP_SENSE: 0 means no negative response received or sent; otherwise, 
contains the sense data from the negative response 
RH: contains request/response header (see SNA Formats). 
RQ_CODE: contains the valid RU request codes that can be received by the 
half-session; possible values: CRV, BIS, LUSTAT, RTR, SIG, OTHER | firs 


COMMON_CB 


This is the definition of the common control block passed to the routines for 


session-level pacing. The calling process initializes the COMMON_CB during its initial- 
ization processing (except for the RESERVE_FLAG and UNSOLICITED_NWS). 


COMMON_CB me 

CALLER: the calling process | 
PATH_CONTROL_ID: ID of the path control instance used by this LU 
LFSID: local-form session identifier associated with the HS (see page A-28) 
PERM_POOL_ID: ID of the permanent buffer pool to be used by HSs within this LU 
DYNAMIC_BUFFER_POOL_ID: ID of the dynamic buffer pool to be used by the 
half-session to receive normal-flow requests | 
LIMITED_BUFFER_POOL_ID: ID of the limited buffer pool to be used by the 
half-session to send normal-flow requests 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
NUM_BUFS_PER_RU: number of buffers needed for each RU (always set to 1 by HS) a 
RESERVE_FLAG: possible values: NO, ALL, MORE ( 
SEND_PACING: information needed for sending data from this LU to the partner LU os 

TYPE: possible values: NONE, FIXED, ADAPTIVE 

RPC: number of MUs that can still be sent in this window 

NWS: size of the next window 

FIRST_WS: size of the first window when the session started (fixed window size 

when fixed pacing is used) 

SET_RLWI: indicates if the RLWI should be set to 1 (RLW) when the next pacing 

request is sent (always set to NOT_RLW for fixed pacing) 

RECEIVE_PACING: information needed for receiving data from the partner LU 

TYPE: possible values: NONE, FIXED, ADAPTIVE 

RPC: number of MUs that can still be received in this window 

NWS: size of the next window 

UNSOLICITED_IPM_OUTSTANDING: indicates if an IPM ACK is expected on from the 

partner LU; set to TRUE when waiting for an IPM ACK 

ADJUST_FOR_IPM_ACK_OUTSTANDING: indicates IPM ACK has been received but the 

limited buffer pool hasn't been adjusted yet 
UNSOLICITED_NWS: window size in an unsolicited IPM received from the 
partner LU | 


6.0-8 SNA LU 6.2 Reference: Peer Protocols 


Co 


a“ 


CHAPTER 6.1. 


DATA FLOW CONTROL 


INTRODUCTION 


OVERVIEW 


The basic function of data flow control (DFC) 
component is to control the flow of data 
between half-sessions. DFC and FMD RUs flow 


OF DFC FUNCTIONS 


DFC performs the following functions: 


e Request/Response Formatting: DFC 
enforces correct RH parameter settings 
for FMD and DFC requests and responses. 


® Chaining Protocol: Chaining is a means 
of sending or receiving a group of RUs 
for which there will be at most one 


response. DFC enforces the chaining pro- 
tocol. 

®  Request/Response Correlation: DFC corre- 
lates responses with their associated 
requests. 


e¢ Request/Response Mode Protocols: Immedi- 
ate request and immediate response modes 
are enforced by DFC. 


e Send/Receive Mode Protocols: The 
normal-flow send/receive mode 
(half-duplex flip-flop) specifies a par- 
ticular form of coordination between 
sending and receiving of normal-flow 


requests and responses. 


e Bracket Protocols: Bracket protocols 
provide a means of sending or receiving a 


DFC STRUCTURE 


The DFC structure is shown in Figure 6.1-1 on 
page 6.1-2. 


INITIALIZATION 


The DFC initialization procedure is called by 
the half-session router (see "Chapter 6.0. 
Half-Session") at the activation of each ses- 
sion. It initializes FSMs and other protocol 
related parameters to be used during the ses- 
sion. 


through the DFC component; network control 
(NC) and session control (SC) RUs do not. 
All sessions use FM profile 19. 


sequence of chains as a delimited trans- 
action entity. 


e Purging: When a bracket error negative 
response is sent for an incoming begin 
bracket (BB) chain, the remainder of that 
chain is purged. 


e Buffer Management: 


— DFC specifies FREE_BUFFER in the Call 
to the buffer manager to release the 
buffer in which an MU was received or 
an error was detected. 


—- DFC specifies ADJUST_BUF_POOL’ to 
allow the buffer manager to reduce 
the size of a limited buffer pool to 


reflect the correct send pacing 
count. 
—- DFC specifies ADJUST_BUF_POOL’ to 


request the buffer manager to Keep 
the same size of a dynamic buffer 
pool. 


—- DFC specifies GET_BUFFER to request 
the buffer manager to allocate a per- 
manent buffer for building an MU. 


SEND 


DFC procedures receive records (e.g., from 
presentation services and the resources man- 
ager), process the records, and send them on 
to transmission control (TC). The send proc- 
essing consists of setting RH bits and MU 
header fields, and updating the states of DFC 
send FSMs. 
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Note: 


Figure 6.1-1. 


PROTOCOL 


Vv 
Buffer Manager (BM) < 


Presentation Resources 


Services (PS) 


HS Router 


| 
| 
| 
Vv 


DFC_ 
INITIALIZATION 
(Note ) 


DFC 
SEND Procedures 


<> 


Manager (RM) 


DFC_RCV 
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DFC is called by the half-session router (See "Chapter 6.0. Half-Session") at 
session-activation time. 


Overview of DFC 


RECEIVE 


The DFC receive procedures (page 6.1-24, page 
6.1-25 ) receive MU records from TC, process 
them, and send them on to PS or RM. When DFC 
receives records from RM or PS, it creates 
MUs to carry the information and sends to the 
DFC send procedure (page 6.1-27). DFC_RCV 
optionally checks the MU records for receive 
error conditions. These are conditions that 
occur only when the other half-session has 
violated the architecture. When DFC_RCV 
detects an error condition, it sets the sense 
code to indicate the error and returns to the 


BOUNDARIES 


DFC sends, receives, and processes records. 
The records DFC sends to» and receives from, 
RM and PS represent commands and replies 
unique to DFC's protocol boundaries with RM 
and PS. DFC maps the commands and replies it 
receives from RM and PS into MU records suit- 
able for its processing; similarly, it maps 
MU records into commands and replies suitable 
for processing by RM and PS. The records DFC 
sends to, and receives from, TC are MU 
records that represent RU chains. See SNA 
Formats for details. 
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half-session router. The router will then 
cause the half-session to be deactivated. If 
no receive errors are detected, the DFC_RCV 
processing consists mainly of updating the 
states of DFC receive FSMs (page 6.1-25). 


TERMINATION 


DFC and other half-session components stay 
active until a deactivation RU (UNBIND or 
-RSP(BIND)) flows. DFC causes an UNBIND to 
be sent when an error is detected. See Chap- 
ter 6.0. 


The protocol boundary information (records 
exchanged) 1s summarized in Figure 6.1-2 on 
page 6.1-3. The detailed specifications of 
the protocol boundaries with PS, RM, BM, and 
TC appear in the individual DFC procedures. 


Throughout this chapter, references’ to 
request RUs and response RUs pertain to the 
MU records that represent the requests and 
responses. References to the sending or 
receiving of requests and responses pertain 
to the protocol boundary with TC, unless 
stated otherwise. 
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6.1-4 


FM profiles are used to convey information 
about the protocols used on a session. FM 
profile 19 is used for half-sessions using LU 
6.2 protocols. The DFC requests for this 
profile are BRACKET INITIATION STOPPED (BIS), 
LOGICAL UNIT STATUS (LUSTAT), READY TO 
RECEIVE (RTR), and SIGNAL (SIG). These 
requests are used to control the flow of data 
between the paired half-sessions and are 
described in "DFC Request and Response 
Descriptions" on page 6.1-16. 


The FM usage settings in BIND are as follows: 


e Chaining use (primary and _= secondary): 
multiple RU chains. 


° Request control mode selection (primary 


and secondary): immediate. 

e Form of response requested (primary and 
secondary): RQE or RQD. 

e Compression indicator (primary and sec- 


ondary): no compression. 


° Send CEB indicator (primary and second- 


ary): either end may send CEB. 
e FM header usage: FMH-12( Security), 
FMH-5( Attach), and FMH-7( Error 


Description). 


CONDITIONAL END BRACKET (CEB) 


The CEB is used to indicate bracket termi- 
nation. It is allowed only on an RH with EC. 
The bracket is terminated in all cases except 
when a -RSP to a (CEB,RQD2|3) chain leaves 
the session in-bracket (INB). The bracket 
terminates in all other circumstances. (See 
"Bracket Protocols" on page 6.1-10 for more 
details on bracket termination. ) 


FM HEADER USAGE 


The Format indicator (FI), set to FMH, and RU 
Category (RU_CTGY) field, set to FMD, in the 
RH are used to indicate the presence of an FM 


header immediately following the RH. The FM 
headers for LU 6.2 are  FMH-5(Attach), 
FMH-7( Error Description), and 


FMH-12(Security); See SNA Formats’ for 
details. 

The FMH-5S(Attach) may be carried in an RU 
with the Begin Chain indicator (BCI) set to 
BC. It may also be sent with BCI set to -BC 
when it is sent in an RU immediately follow- 
ing an FMH-12 that was (-EC,-CEB). 


The FMH-7(Error Description) may appear in 
any RU in a chain at any time during the life 
of a bracket; it may be followed by data 
(1.e., 1t does not terminate the chain) or it 
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@ Brackets: brackets are used and the 
reset state is in-brackets. 
conditional 


e Bracket termination rule: 


termination. 


e Alternate Code Set Allowed indicator: 
may or may not be used. 


e Normal-flow send/receive mode: 
half-duplex flip-flop. 

e Recovery responsibility: symmetric. 

¢ Contention winner/loser: primary 


half-session (BIND sender) or secondary 
half-session (BIND receiver). The state 
is determined at BIND time (for parallel 


sessions, it is not negotiated). (See 
"Chapter ¢. LU Session Manager") This 
determines who is bidder’ (contention 
loser ) 


tention winner). 


e Half-duplex flip-flop reset states: BIND 
sender is in send state after +RSP(BIND). 


More detail of FM usage settings, and the 
formats and protocols implied by them, appear 
in the following pages. 


may terminate a chain. The FMH-7 is not 
related to or bound by the chain state; it 
may be sent in ae (BC,-EC), (-BC,-EC), 
(-BC,EC), or (BC,EC) request. 


The FMH-12(Security) may flow only as_ the 
first RU after the session is initiated. If 
cryptography is in effect, the FMH-12 flows 
after the CRV exchange is complete. FMH-12 
is always sent in a (BC,RQE1) request. The 
request may indicate either (EC,CEB) or 
(-EC,-CEB); the latter is used when the next 
request carries an FMH-5 with -BC. 


USAGE OF DR1 


DR1 is sent in a positive response to an RQD1 
request in order to indicate that the 
requested function has been performed. The 
following are the only uses of DR1 in +RSP. 


1. When the sender of Attach elects to bid 
for the session without sending = an 
Attach, it may do so with an (RQD1,BB) 
LUSTAT(0006). The receiver sends' the 
+DR1 when the session has been "“allo- 


C- 


and who is first speaker (con- (~ 


cated" to the sender. The only request 
that may follow this sequence is an 
FMH-5( Attach) to attach a_ transaction 


program or LUSTAT with (RQE1,CEB) to can- 


cel the bid. (See "Chapter 3. LU. 
Resources Manager" for more details on 
bidding. ) 


“. 
» 
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2. When RTR flows (RTR is always sent RQD1. ) 


3. When (RQD1,BB,CEB,Attach,data...) 1s 
received, i.e.» a Bid with data 


G4. When (RQD1,CEB) is received as a result 
of the remote transaction program issuing 
the DEALLOCATE verb with the ABEND option 


5. When (RQD1,CEB) is received at sequence 
numbering wrap points, as part of the 
stray SIGNAL and stray response logic 
{see "Stray SIGNALs and Responses") 


SENDING RQE WITH BB FROM CONTENTION LOSER 


The contention loser is allowed to = send 
(RQE*,BB,CD,FMH-5,data) as a Bid. 


USAGE OF RQE1, CEB, LUSTAT( 0006) 


Sessions are activated in the in-brackets 
(INB) state. If, for some reason, RM decides 
a newly activated session is not needed, it 
sends a YIELD_SESSION signal to DFC (see 
"Chapter 3. LU Resources Manager"). This 
results in an RQE1, CEB, LUSTAT(0006) being 
sent to terminate the unused bracket. 


USAGE OF SIGNAL(X'00010001' ) 


PS issues the REQUEST_TO_SEND command to DFC 
when the conversation is in receive state, 
requesting that the conversation be placed in 
send state (see "Send/Receive Mode Protocols" 
on page 6.1-11). SIGNAL always uses the 
REQUEST_TO_SEND code (X'00010001'). DFC then 
sends SIGNAL to the other half-session. When 
+RSP(SIG) is received, DFC passes’ the 
RSP_TO_REQUEST_TO_SEND reply up to PS. The 
conversation enters the send state when an RU 
carrying CD is received. 


SEQUENCE NUMBERING OF REQUESTS AND RESPONSES 


DFC assigns sequence numbers to DFC and FMD 
requests and responses, as follows: 


¢ For normal-flow requests, the send 
sequence number count is incremented by 1 
and then assigned to the request. 


e¢ =€636©6A normal-flow BB response is assigned the 
sequence number of the corresponding BB 
request. The high-order bit is 0 if the 


bracket was started by the secondary 
half-session, or 1 if the bracket was 
started by the primary half-session. 


e SIGNAL (the only expedited-flow DFC 
request) and all responses are assigned 


the sequence number of the current brack- 
et. 


e 6A normal-flow RTR response is assigned 
the sequence number of the corresponding 
RTR request. 


Figure 6.1-3 on page 6.1-6 illustrates an 
example of the use of sequence numbers. In 
this figure, some session control RUs (BIND; 
UNBIND, and CRV) are also illustrated. 


STRAY SIGNALS AND RESPONSES 


When a request is sent (RQE1,CEB) or 
(RQD*¥,CEB), a stray SIGNAL or response can 
occur. This happens because SIGNALs are 
expedited and are sent in receive state. A 
stray SIGNAL or response is one that is 
received outside the bracket it is intended 
for, and that could be disruptive if not 
eliminated or not recognized as a stray. 
SIGNALs received outside the intended bracket 
may be “early” or "late." "Early" SIGNALs 
are those received in a bracket that was 
started prior to the bracket in which the 
SIGNAL was generated. "“Late"™ SIGNALs are 
those received in a bracket that was started 
after the bracket in which the SIGNAL was 
generated. Responses received outside the 
current bracket are always "late." Examples 
are shown in the following figures. 


SIGNAL or -RSP 


RQE1,CEB 


Bracket B gets the SIGNAL intended for A. 


Figure 6.1-4. Case 1: “Late™ SIGNAL or 
Response 
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sequence number in this case is an identifier, 
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which can have any value 0-65535. 


2. The sequence number in this case is an identifier, which has the same value as the request. 


3. The first normal-flow RU following the BIND begins the first bracket. The session comes up in 


bracket for efficiency. 
first data RU is 1. 
request. 


The implicit bracket sequence number is 0, the sequence number of the 
After the first bracket is ended, subsequent brackets begin with a BB 
The bracket sequence number is the sequence number that flowed on the BB request. 


4. The sequence number in this case is an identifier, which has the following properties: 


Figure 6.1-3. 
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The low-order 15 bits are the same as the low-order 15 bits of the sequence number that 


started the bracket. 


The high-order bit is 0 if the bracket was started by the secondary half-session, or 1 if the 
bracket was started by the primary half-session. 


Use of Sequence Numbers 


Peer Protocols 


RQE1,CEB 


RQE* ,BB ,CD 


SIGNAL 


Bracket A gets the SIGNAL intended for B. 


Figure 6.1-5. Case 2: "“Early™ SIGNAL 


RQD* ,QR,CEB 


+RSP ,QR 


RQE* »BB,CD 


SIGNAL 


Bracket A gets SIGNAL intended for B. 
Figure 6.1-6. Case 3: "Early" SIGNAL 


The following subsections discuss how prob- 
lems with strays are avoided. 


Sending SIGNAL and Responses 


Each LU eliminates problems with = stray 
SIGNALs and stray responses by Keeping three 
16-bit “bracket ID" registers, a 1-bit 
switch, and a 15-bit normal-flow request 
counter: 


¢ PHS BB_REGISTER 


Bit 0: 1 

Bits 1-15: Low-order 15 bits of TH 
sequence number’ of last BB 
request sent by (or received 
from) primary  half-session 
(PHS ) 


® SHS _BB_REGISTER 


Bit 0: 0 

Bits 1-15: Low-order 15 bits of TH 
sequence number of last BB 
request sent by (or received 
from) secondary half-session 
(SHS ) 


e CURRENT_BRACKET_SQN 


Bit 0: 1 = Bracket started by PHS 
0 = Bracket started by SHS 
Bits 1-15: Low-order 15 bits of TH 


sequence number of current 
bracket | 


e An indication that a definite response is 
required on the next CEB 


Bit O: 0 = No RQD required on next 
CEB sent 
1 = RQD required on next CEB 
sent 


e = =6A count of normal-flow requests 


Bits 0-14: A count of the number of 
normal-flow requests sent and 
received since the last-sent 
(RQD ,CEB ) 

When a normal-flow response (except for 


RSP(RTR)} or a SIGNAL is sent, DFC places the 
contents of the CURRENT_BRACKET_SQN register 
in the sequence number field (SNF) of the 
response or SIGNAL. The current. bracket 
sequence 1s not used for RSP(RTR) because it 
does not flow within a bracket. 


RQD required on CEB 


RQD is required on some CEB requests to ena- 
ble proper recognition of stray SIGNALs and 
stray responses. Since the CUR- 
RENT_BRACKET_SQN field is 15 bits, an identi- 
cal value can occur after 2**15 RUs flow, 
causing the field to wrap. This can lead to 
confusion when recognizing stray SIGNALs and 
stray responses. In order to avoid this con- 
fusion, the normal flow is cleaned out peri- 
odically by the use of an (RQD,CEB) request 
and its response. This results in the fol- 
lowing: 


1. Whenever the count of normal-flow 
requests reaches 2%**14¢, the indication 
that a definite response is required on 
the next CEB is set to YES. 


2. Whenever the indication that a definite 
response is required on the next CEB is 
set to YES, the next CEB request is sent 
using RQD1, RQD2, or RQD3. The indi- 
cation that a definite response is 
required on the next CEB is then reset to 
NO and the count of normal-flow requests 
is reset to 0. If DFC receives the CEB 
with an indication to send it RQE1 (e.g., 
the transaction program issued DEALLOCATE 
with the FLUSH option), DFC will change 
it to RQD1 in order to comply with this 
rule. When a response is received to an 
(RQD1,CEB) request, no information is 
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6. 
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forwarded to PS because the transaction 
program is no longer communicating with 
the half-session. 


Receiving SIGNAL Requests 


When SIGNAL is received, the DFC component of 
the half-session does the following: 


1. Validates the SIGNAL code--1if it is other 
than request_to_send (X‘'00010001'), an 
UNBIND indicating protocol error 
(X'FE,10050000') is sent. The SIGNAL 
response is sent immediately. This cre- 
ates the potential for receiving further 
SIGNALs before this one is processed. A 
l-deep queue for SIGNAL is defined, so 
later SIGNALs overlay earlier ones. If 
overlaying occurs, the receiving trans- 
action program gets only a single indi- 
cation that a SIGNAL has been received; 
even though more than one SIGNAL has been 
sent. This is sufficient since all 
SIGNALS indicate request-to-send. 


2. Places the SIGNAL in the correct brack- 
et--the TH identifier field (SNF) is com- 
pared against the CURRENT_BRACKET_SQN 
register. 

° If they are equal, the SIGNAL is 
accepted and processed. 


e If the SIGNAL is early (see Fig- 
ure 6.1-5 on page 6.1-7 and Fig- 
ure 6.1-6 on page 6.1-7), it is 
pushed into the correct bracket by 
saving the SIGNAL value until the 
correct BB arrives, which can be 
several brackets in the future. 


e If the SIGNAL is late (see Fig- 
ure 6.1-4@ on page 6.1-5), it is dis- 
carded because the transaction 
program is no longer communicating 
with the half-session (1.e., the con- 
versation has ended). 


3. Reports receipt of the SIGNAL, via a 
REQUEST_TO_SEND record, to the PS compo- 
nent of the transaction's process. See 
"Chapter 5.1. Presentation 
ices--Conversation Verbs" for 
discussion of the PS logic. 


further 


Receiving Responses 


When a response is received, the DFC compo- 
nent: 
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1. Identifies failures--format checking and 
invalid sense code values are detected 
and a conversation failure is reported to 
PS and RM. An UNBIND(X'FE....°) with 
sense data from the negative response is 
sent to terminate the session itself. 


2. Detects stray negative responses--the TH 
identifier field (SNF) of the response is 
compared against the CURRENT_BRACKET_SQN 
register. If they are equal, the -RSP is 
intended for the current chain. If the 
-RSP is late (see Figure 6.1-4 on page 
6.1-5), it is discarded because _ the 
transaction program the response is 
intended for is no longer communicating 
with the half-session. (If a positive 
response, other than +RSP(SIG), is not in 
the correct bracket, an UNBIND protocol 
error (X'FE,200E0000') is sent; +RSP(SIG) 
is discarded. ) 


3. Reports RTR responses--responses to RTR 
are reported to RM without regard for the 
bracket boundaries. 


G. Reports responses to RQD1 requests--in 
general, responses to RQD1 requests, such 
as a Bid request (LUSTAT with (RQD1,BB)), 
are reported to RM; an exception is 
RSP(SIG), which is reported to PS. 


and RQD3 
and RQD3 


5. Reports responses to RQD2 
requests--responses to RQD2 
requests are reported to PS. 


SEND_ERROR PROCESSING 


PS issues the SEND_ERROR command to DFC when 
PS is in HDX receive state, in order to 
change to send state so that it (PS) can send 
FMH-7(Error Description). (If already in 
send state, PS sends the FMH-7 without issu- 
ing the SEND_ERROR command; see "Chapter 5.0. 
Overview of Presentation Services" for more 
details. ) Issuing SEND_ERROR in receive 
state causes DFC to send -RSP(ERP message 
forthcoming--X'084¢6') if some data has been 
received. If no data has been received, DFC 
waits until a chain is received and then 
responds with -RSP(X'0846' ). 


After the EC request is received, PS can send 
the FMH-7(Error Description); the FMH-7 
includes sense data for PS's use and is not 
processed by DFC. If the EC request ended 
the bracket, PS does not send the FMH-7. 


—. 


DETAILED 


DESCRIPTION OF DFC FUNCTIONS 


REQUEST/RESPONSE FORMATTING 


one 
\ 
/ 


CHAINING 


7 
~~ 


DFC optionally checks that the requests and 
responses it receives are formatted correct- 
ly. The formatting checks involve: 


e §€686—Enforcing that invalid RH bit combina- 
tions are not used, e.g.» BBI=BB and 
BCI=-BC, or CDI=CD and ECI=-EC. 


e Enforcing that the FM profile 19 rules 
are not violated, e.g., the receiving of 


PROTOCOL 


Chaining provides a means to send (and 
receive) a sequence of requests as one entity 
in the context of error recovery. At most 
one response is sent per chain. 


A chain consists of a single response RU or 
one or more request RUs with the following 
properties: 


e The requests belong to the same flow (ex- 
pedited or normal). 


_@ The requests flow in the same direction. 


ye 
4 \ 
\ 


e The first request is marked BC (Begin 


Chain) in the RH. 


e The last request is marked EC (End Chain) 
in the RH. 


e All requests that are neither first nor 
last are marked (-BC, -EC) in the RH. 


The checking of received requests for proper 
chaining is provided for each half-session. 


Each response and each expedited-flow request 
1s a single-RU chain, i.e., the RH indicates 
(BC,EC). 


REQUEST/RESPONSE CORRELATION 


a 
F ‘ 
fa 
v 


In order to remember the information = on 


normal- flow chains that DFC  sends’- or 
receives, DFC maintains two correlation 
entries: one for sent chains and one for 


received chains. There can never be more 
than one sent or received chain outstanding 
at any point in time (FM profile 19 protocol 
rules do not allow it), hence the need for 
only two entries. A correlation entry is 


an expedited-flow DFC request other than 
SIGNAL, or the receiving of a request 
with BB that is neither LUSTAT nor FMH-5 
(Attach). 
Format checks occur before the use of 
finite-state machines (FSMs). (State checks 
are checks that involve FSMs.) FSMs require 
the BIU record to be formatted correctly 
before processing it. 


Only chains of the following types are sent: 


e Exception-response (RQE) chain: Each 
request in the chain 1s marked 
exception-response. 

e Definite-response (RQD) chain: The last 
request in the chain is marked 


definite-response; all other requests in 
the chain are marked exception-response. 


See SNA Formats for details of the possible 
variations within each type. 


The sender of the chain sets the Form of 
Response Requested bits properly in_ each 
request of the chain. Thus, the receiver of 
a chain need examine the Form of Response 
Requested bits only in the last request in a 
chain, or in a request in error. 


Normal-flow DFC requests are not sent while 
sending a normal-flow FMD multiple-request 
chain. 


If a chain sender receives a_ negative 
response to a chain being sent, the chain may 
be ended prematurely by ~ sending the 
end-of-chain (EC) request. 


established when the first RU in a chain is 
sent or received. The entry is reset when 
the chain has been completely processed, that 
is» when the end-of-chain request and its 
response, if any, have been processed. A 
correlation entry includes such information 
as selected RH parameters needed by DFC 
(e.g., RU category, BBI, and CEBI), and the 
DFC request code. 
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Some examples of how the correlation entry is 
used are: 


e When receiving a response, the entry for 
the sent chain is checked to verify that 
the RU category in the response is the 
same as the RU category of the sent 
chain. 


REQUEST/RESPONSE MODE PROTOCOLS 


Every half-session issues requests and 
responses according to the immediate request 
mode and the immediate response mode. Imme- 
diate request mode means that all request 
chains are sent under the constraint that no 
request may be sent by a given half-session 
when a previously sent request is still 
awaiting a response or reply. (A reply is a 
request sent in reaction to a received RQE 
request unit.) Request chains are replied or 
responded to in order of receipt. DFC 
enforces immediate request and response mode 
in the chaining FSMs. 


Only two expedited RUs are used (SIG and CRV) 
and both use the immediate request mode. The 
two RUs flow at different times (when in use, 


BRACKET PROTOCOLS 


6.1-10 


A bracket is a sequence of normal-flow 
request chains and their responses, exchanged 
in either or both ‘directions between two 
half-sessions. Bracket protocols allow con- 
tention for session resources and assist in 
resolving the race condition that can result 
from that contention. 


The primary use of brackets is to carry con- 
versations between transaction programs. A 
transaction program requests a conversation 
with another transaction program by issuing 
the ALLOCATE verb. ALLOCATE causes’ the 
resources manager (RM) to select a 
half-session (based on ALLOCATE parameters) 
and attempt to initiate a bracket on it. If 
the bracket is successful, that half-session 
is used to carry the conversation. (See 
"Chapter 3. LU Resources Manager" for more 
details.) A transaction program ends a con- 
versation by issuing a DEALLOCATE verb. This 
causes the half-session to terminate the 
bracket carrying the conversation. When the 
bracket terminates, the half-session becomes 
available again for selection by RM. 


A bracket is delimited by setting BBI to 
Begin Bracket (BB) in the first request of 
the first chain, and CEBI to Conditional End 
Bracket (CEB) in the last request of the last 
chain in the bracket. 


BIND parameters specify one of the 
half-sessions as first speaker and the other 
as bidder. The first speaker has the freedom 
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e When sending a response, the entry for 
the received chain is examined to deter- 
mine whether a bracket has begun (1i.e., 
the first RU in the chain was FMD with 
BBI=BB, or the single-RU chain was LUSTAT 
with BBI=BB). 


the .CRV exchange is complete before SIG is 
ever sent), and therefore the protocol can be 
enforced by the initiating components--DFC 
enforces the protocol for SIG, and MTC 
enforces it for CRV. 


The immediate response mode requires that 
responses be sent in the order the requests 
are received (1i.e., requests are processed 
and responses issued first-in, first-out). 
When a response to a particular request is 
received, it means that all requests in the 
same flow sent before the  responded-to 
request have been processed by the receiver, 
and that their responses, if any, have been 
sent. 


to begin a bracket without requesting permis- 
sion from the other half-session to do so. 
Any request carrying BB sent by the first 
speaker will begin a bracket. The bidder 
must request and receive permission from the 
first speaker to begin a bracket. The brack- 
et protocols are verified by the bracket 
state manager in the receiving half-session. 


The bidder may attempt to initiate a bracket 


(1.e., Bid) by sending an FMD request chain 
with (RQD,BB,QR) or with (RQE,BB,CD,QR). 
(See "“Queued Response Protocol" on page 


6.1-12 for description of QR usage.) The 
first speaker grants the attempt via a reply 
to an (RQE,CD) (see "Send/Receive Mode Proto- 
cols" on page 6.1-11 for definition of reply) 
or a positive or negative response (other 
than X'0813', X'0814¢', or X'088B') or refuses 
the attempt via negative response (X'0813', 
X'081¢', or X'O88B' ). 


A negative response with sense code X'0813', 
X'0814', or X'O088B' indicates that the first 
speaker has denied permission for the bidder 
to begin a bracket. A Ready_To_ Receive (RTR) 
request may be sent later by the first speak- 
er when permission to start a bracket is 
granted. (The first speaker may or may not 
have the capability to subsequently send RTR. 
The X'081¢' sense code is used only when the 
first speaker has the capability to send 
RTR.) If the first speaker will send RTR 
later, the sense code with the negative 
response is X'0814¢' (Bracket Bid Reject--RTR 


C- 


nd 


Forthcoming). In this case, the bidder waits 
for the RTR before sending another BB. If 
the RTR will not be sent, the sense code is 
either X'0813' (Bracket Bid Reject~-No RTR 
Forthcoming?) or X'088B' (BB Not Accepted--BIS 
Reply Requested). In the X'0813' case, the 
bidder will send BB again, if it still wants 
to begin a bracket. In the X'088B' case, the 
BB is not sent again because no more conver- 
sations will be allowed to start. <A BIS 
request will be received shortly and a BIS 
reply will be sent. 


Expedited requests and responses are not 
affected by bracket indicators on normal-flow 
requests, nor by the states of the bracket 
FSMs. 


BRACKET RULES 


The following rules apply to the bracket 
indicators: 


¢ BB may be indicated only on the first (or 
only) request of the first chain. 


¢ CEB may be indicated only on the last (or 
only} request of the last chain. It 
indicates the last chain in the bracket. 
(If CEB is set, CD must not be indicated 
because CEB overrides CD.) 


e BB and CEB may both be indicated within 
the same chain. 


e BB or CEB may be indicated by either 
half-session. 


e BB or CEB may be indicated on FMD 
requests. 


e Neither BB nor CEB may be indicated on 
any normal-flow DFC request except 
LUSTAT. 


e Neither BB nor CEB may be indicated on 
responses or on expedited requests. 


The following bracket termination rule is 
used: 


e Bracket Termination Rule: Bracket termi- 
nation is influenced by whether the RU 


SEND/RECEIVE MODE PROTOCOLS 


Once a bracket has started, the normal-flow 
send/receive mode protocol is_ half-duplex 
flip-flop (HDX-FF). One half-session is des- 
ignated HDX-FF bidder, and the other, HDX-FF 
first speaker. Parameters in BIND specify 
which half-session is first speaker and which 
1s bidder. The bidder may send a request 
containing BB, but its bid for the bracket is 
pending until it receives a response. 


Once a bracket is begun, a_half-duplex 
flip-flop state is established, and the send- 


carrying CEB is an RQ@E, RQD1, or RQD2]|3, 
request. If the request is RQD2|3 the 
bracket terminates only upon receipt of a 
positive response; a negative response to 
the chain causes the session to remain in 
bracket. If the RU is sent as RQE, the 
bracket terminates unconditionally upon 
the sending of that RU. A negative 
response to an (RQE,CEB) request will not 
find an entry in the receive correlation 
entity, and therefore is logged and dis- 
carded. If the RU is specified as RQD1, 
the bracket terminates unconditionally 
upon receipt of a response to the chain, 
whether the response is positive or nega- 
tive. RQD1 is generated by DFC for the 
sequence number wrap case (unless the 
request is already RQD2|3) and for the 
DEALLOCATE TYPE(ABEND_*) verb. When DFC 
uses RQD1, PS and the transaction program 
consider the conversation to be termi- 
nated when the DEALLOCATE TYPE( ABEND_*) 
or DEALLOCATE TYPE( FLUSH) verb is issued: 
PS and the TP don't expect a response. 
DFC waits for a response before informing 
RM that the session is available for a 
new conversation. 


No more than one BB can be outstanding from a 
half-session unless the LU is the first 
speaker and is not waiting for any type of 
response or reply. 


The normal-flow DFC requests, RTR and BIS; 
may be sent only between brackets and do not 
carry bracket bits. FMD requests always car- 
ry BB when flowing between brackets. LUSTAT 
is treated exactly like an FMD request con- 
taining (BC,EC), and may be used with BB to 
bid for, or with CEB to end, a bracket. 


The following types of error conditions are 
detected in the management of brackets: 


e Bracket protocol errors detected at the 
receiver and caused by sender error. 


e Errors detected at the receiver and 
caused by race conditions. The appropri- 
ate action is for the receiver to send a 
Bracket Bid Reject sense code (X'‘'0813', 
X'0814¢', or X‘'088B') on aie negative 
response to the other half-session. A 
retry of the operation may be necessary. 


er issues normal-flow requests and the 
receiver issues responses. When the sender 
completes its transmission of normal-flow 
requests, it transfers control of sending to 
the other half-session by setting the Change 
Direction indicator to CD on the last request 
sent. See "Bracket Protocols" on page 6.1-10 
for additional details. 


The Change Direction indicator (CDI) is used 


in the HDX-FF protocols. Only a request on 
the normal flow that is marked End Chain may 
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carry CDI=CD. When the sending half-session A "reply" is the request sent by a 


includes CD in a request, it indicates that half-session immediately after receiving an/ ~ 
it is prepared to receive and that its paired) (RQE,CD) chain. A reply is treated asi 
half-session may send. CD is not conveyed in implicitly containing a positive response. ~— 
a response or on a request that carries CEB. That is, once an (RQE,CD) chain is replied 

to, a negative response to that chain is not 
An exception-response (RQE) chain always has permitted. A BIS, RTR, or an RU carrying BB 
CD indicated on the last RU of the chain, is not treated as a reply. 


unless that RU carries CEB, in which case it 
does not indicate CD. 


QUEVED RESPONSE PROTOCOL 


DFC enforces the setting of the Queued pass any other RUs flowing through the net- 

Response Indicator (QRI) bit (in RH) = on work on the same session. It is used so that 

requests. The setting of the QRI bit is the a positive response to the bidder's BB chain 

same for all RUs in a chain. See SNA Formats will not interfere with a bracket sent earli- 

for a discussion of this RH indicator. er by the first speaker. The positive -— 
response will be received after the first/ | 

QR is always indicated on a chain carrying BB speaker's bracket ends. QR is not indicated \___. 

that 1s sent by the bidder. When QR is indi- on any other chain. | 


cated in a response, that response will not 


PS SEND AND RECEIVE RECORDS 


This section describes how the request BIU by DFC before being sent. The MU 
SEND_DATA_RECORD (sent from PS to HS) and the sent from the half-session to PS carries the 

MU (sent from HS to PS) are mapped to and data received on the half-session and is/ 
from the RH portion of a BIU containing a mapped from aé=ereceived BIU_ containing ay ; 
request RU. The SEND_DATA_RECORD is used by request. Figure 6.1-7 on page 6.1-13 summa- ~~ 
PS to send data in accordance with the verbs rizes the SEND_DATA_RECORD to RH mapping and 
issued by a transaction program. This record Figure 6.1-8 on page 6.1-13 summarizes the RH 

(see "Chapter 5.0. Overview of Presentation to MU (send from HS to PS) mapping. 


Services" for details.) is mapped into a 
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C. Parameters in SEND_DATA_RECORD Request RH indicators 
(from PS to HS) 

ALLOCATE=YES (see Note 1) BB 

FMH=YES (see Note 1) FMH 


FLUSH 


CONFIRM | EC »RQD3 
PREPARE_TO_RECEIVE_CONFIRM_SHORT EC,CD,RQD3 
PREPARE_TO_RECEIVE_CONFIRM_LONG EC ,CD,RQE3 


PREPARE_TO_RECEIVE_FLUSH EC ,CD,RQE1 
DEALLOCATE_CONFIRM EC ,CEB,RQD3 
DEALLOCATE_FLUSH with EC,CEB, RQD1 
DEALLOCATE_ABEND_* FM header 
(see Note 3) 
DEALLOCATE_FLUSH without EC,CEB, RQE1 
DEALLOCATE_ABEND_* FM header 


C (see Note 3) 
Notes: 


1. This parameter is used in conjunction with the rest of the parameters (e.g., if ALLOCATE is YES and 
FMH is YES, specified with DEALLOCATE_CONFIRM, the request RH indicators are BB,FMH,EC,CEB,RQD3). 


2. RH indicators not shown (e.g.» QRI) are set independently from the SEND_DATA_RECORD parameters. 


3. To indicate a DEALLOCATE_ABEND_¥ action, FMH is set to YES and DATA (offset 2 through 4) is set to 
x'070864"°. 


-~. Figure 6.1-7. 
| 
C) 
Request RH indicators 


FMH 


Mapping from SEND_DATA_RECORD to request RH 


Parameters set in MU 
(sent from HS to PS) 
FMH=YES (see Note 1) 


NOT_END_OF_DATA 


' EC,RQD2|3 CONFIRM 


EC ,CD ,RQ¥2|3 PREPARE_TO_RECEIVE_CONFIRM 
EC ,CD,RQEl PREPARE_TO RECEIVE FLUSH 


EC CEB ,RQD2 |3 DEALLOCATE_CONFIRM 
EC,CEB,RQE1 or RQD1 DEALLOCATE_FLUSH 


Notes: 


1. This parameter is set in conjunction with the rest of the parameters (e.g., if FMH»EC,CEB,RQD2|3 
are indicated in the RH» FMH is YES and DEALLOCATE_CONFIRM is indicated in the MU sent to PS). 


2. Other RH indicators (e.g.», QRI) have no effect on the MU parameter settings. 


Figure 6.1-8. Mapping from request RH to MU (sent to PS) 


®@ 
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DFC REQUEST AND RESPONSE FORMATS 


This section describes the DFC request and 
response formats; the RH formats are shown in 
this section; the RU formats are shown in SNA 
Formats. Figure 6.1-9 and Figure 6.1-10 on 
page 6.1-15 show the format of DFC requests 


and responses, respectively. The Expedited 
Flow indicator (EFI in the TH) shows which 


flow, expedited or normal, the DFC request or 
response flows on. 


SIGNAL 


RH Byte 0 Bit O RRI RQ 
Bits 1-2 RU category 
Bit reserved 
Bit 
Bit 
Bit 
Bit 


RH Byte 1 
reserved 
DR2I 

ERI 
reserved 
reserved 
QRI 

PI 


0 
1 
2 
3 
G 
5 
6 
7 


RH Byte 2 BBI 
EBI 
CDI 
reserved 
reserved 
reserved 
reserved 


CEBI 


NQU PWN FO 


l. *XX means either XX or ~XxX. 

Z. See SNA Formats for complete RH description. 

3. For LUSTAT: If CEBI is set to CEB, CDI is set to -CD. 
4. For LUSTAT: (DR1I,DR2I) = (0,1) | (1,0) | (151). 

5. For LUSTAT: QRI is set to QR when BBI is set to BB. 
6. The SNF and DCF TH fields are also set by DFC. 

7. See SNA Formats for a complete TH description. 


Figure 6.1-9. DFC Request Formats 
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RQ 


RQ 


ase 


(— DFC Response RSP(BIS) RSP(RTR) RSP(LUSTAT) | RSP(SIGNAL ) 
ae Header Indicators | 


: 


RH Byte 0 Bit 0 RRI 
Bits 1-2 RU category 
Bit reserved 
Bit 
Bit 
Bit 
Bit 
RH Byte 1 0 
1 
2 
3 
4 reserved 
5 reserved 
6 QRI 
a, 7 PI 
| 


Notes: 
1. *XX means either XX or -XxX. 
2. See SNA Formats for complete RH description. 


3. For LUSTAT: DR1I, DR2I, and QRI are set the same as they were 
on the request. 


( “ The SNF and DCF TH fields are also set by DFC. 
/ | 
—5. See SNA Formats for a complete TH description. 


Figure 6.1-10. DFC Response Formats 
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DFC REQUEST AND RESPONSE DESCRIPTIONS 


Sa SS | CLE 60 Stee 


The DFC requests FM profile 19 are 


for 
described below. 


BIS (BRACKET INITIATION STOPPED ) 


Flow: 


Principal FSM: 
None in DFC 


BIS is sent by a half-session to indicate 
that it will not attempt to begin any more 
brackets (1.e., send any more BB requests). 


LUSTAT (LOGICAL UNIT STATUS) 


Flow: 


Principal FSM: 
Uses same FSMs as normal-flow data 


LUSTAT is used to accompany RH bits. The sta- 
tus value is set to X'0006'. Specifically, 
LUSTAT is used in place of a null RU; that 
is» when it is time to send an RU to DFC; and 
the RU is marked (BC,EC) and has RU length = 
0, an LUSTAT(0006) is sent instead. This 
results in the following RH encoding with 
LUSTAT( 0006 ): 


“1.  (€RQD1,BB): 
without data. 


Sending half-session bids 


2. (RQE2,CD): Sending half-session trans- 
fers send control to the other 
half-session, specifies that a Confirm be 
taken, and that completion of the Confirm 
be indicated by receipt of the next 
request from the other’ half-session. 
Confirm--means that the transaction pro- 
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The 


er". 


use of BIS and its principal FSMs ane—~ 
described in "Chapter 3. LU Resources Mana: 

PL ae 

Neat 
gram connected to the other half-session 
has received and processed the RU data 
successfully. 
(RQD2,CD): Same as 2, except that com- 
pletion of the Confirm will be indicated 
by receipt of +RSP. 
(RQE1,CD): Sending half-session transfer—_ 
send control to the other erin Seess| 
specifying no Confirm. ead 
(RQD2,CEB): Same as 3, plus the bracket 
will be terminated when a é+RSP_ is 
received. 
(RQE1,CEB): Same as 4, plus the bracket 
is terminated unconditionally. 

a 


Primary to secondary and secondary to primary (Normal) 


Primary to secondary and secondary to primary (Normal) 


= 

4 

; 
C_ 


C 


RTR (READY TO RECEIVE ) 


Flow: First speaker to bidder (Normal ) 


Principal FSM: 
None in DFC 


RTR indicates to the bidder that the bidder 
can now initiate a bracket. An RTR request 
is sent only by the first speaker (see 
"Bracket Protocols” on page 6.1-10). The use 


SIG (SIGNAL } 


of RTR and the RTR bit (in SCB) setting are 
described in "Chapter 3. LU Resources Manag- 
er". 


Flow: Primary to secondary and secondary to primary (Expedited) 


Principal FSM: 
None in DFC 


SIG is an expedited request that can be sent 
between half-sessions, regardless of the sta- 
tus of the normal flows. It is the only 
expedited DFC request defined for FM profile 
19. It carries a four-byte value, of which 
the first two bytes are the signal code and 
the last two bytes are the signal extension 
value. 


The only signal code defined for use with FM 
profile 19 is X'00010001'. This signal code 
is used in conjunction with the PS command 
REQUEST_TO_SEND. See "Chapter 5.1. Presenta- 
tion Services--Conversation Verbs" for more 
details. 
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HIGH-LEVEL PROCEDURES 


6.1-18 
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DFC_INITIALIZE 


DFC_INITIALIZE 


FUNCTION: This procedure initializes fields in the half-session’s local storage (for 
process data) that are used by DFC. 


This procedure is called by the half-session router ("Chapter 6.0. 
Half~Session") when the half-session is created. 


INPUT: INIT_HS, indicating that the half-session is first speaker or bidder 


OUTPUT: DFC local process data fields are initialized and MU information is recorded 


locally 


NOTES: 1. LOCAL.HALF_SESSION is set to indicate that the half-session is primary or sec- 
ondary 


When a half-session is activated, it comes up in-bracket (INB). The first 
data BIU sent on the session uses a value of X'0001' in the TH sequence number 
field and does not’ carry BB. The first BB was implied rather’ than sent. 
Therefore, the current bracket sequence number (LOCAL.CURRENT_BRACKET_SQN) 
associated with the first bracket on a session is initialized to 0. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_BSM_FMP19 page 6.1-50 
FSM_RCV_PURGE_FMP19 page 6.1-56 
FSM_QRI_CHAIN_RCV_FMP19 Page 6.1-55 
FSM_CHAIN_RCV_FMP19 page 6.1-51 
FSM_CHAIN_SEND_FMP19 page 6.1-53 
LOCAL page 6.0-7 
INIT_HS page A-13 
MU page A~-29 


(Record information from the input INIT_HS record that 
will be used by DFC throughout the life of this session. ) 
Set LOCAL.FIRST_SPEAKER to indicate if this HS is a first speaker or bidder. 
Set LOCAL.ALTERNATE_CODE to indicate if an alternate code is allowed. 
Reset correlation table entries. 

Set LOCAL.SQN_SEND_CNT.SQN to Q. 

Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to PRI. 
Set LOCAL.CURRENT_BRACKET_SQN.NUMBER to 0. (Note 2) 

Set LOCAL.PHS_BB_REGISTER.BRACKET_STARTED_BY to PRI. 

Set LOCAL.PHS_BB_REGISTER.NUMBER to O. 

Set LOCAL.SHS_BB_REGISTER.BRACKET_STARTED_BY to SEC. 

Set LOCAL.SHS_BB_REGISTER.NUMBER to 0. 

Set LOCAL.RQD_REQUIRED_ON_CEB to NO. 

Set LOCAL.NORMAL_FLOW_RQ_COUNT to O. 

Set LOCAL.SIG_RECEIVED to NO. 

Set LOCAL.SIG_SNF.SQN to O. 

Set LOCAL.PS_ID to NULL. 

Reset all the FSMs in this chapter to FSM state 1. 
Set LOCAL.BETC to YES. 
Set LOCAL.SEND_ERROR_RSP_STATE to RESET. 

Set LOCAL.BB_RSP_STATE to RESET. i 
Set LOCAL.RTR_RSP_STATE to RESET. 

Set LOCAL.SIG_RQ_ OUTSTANDING to NO. 


If LOCAL.HALF_SESSION is PRI then 
Set LOCAL.SESSION_JUST_STARTED to YES (indicates that the current bracket sequence number 
has already been initialized). 

Else (secondary half-session) 
Set LOCAL.SESSION_JUST_STARTED to NO. 

Save addressability to the MU in LOCAL for later use, before passing it on to PS. 


_ 
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DFC_SEND_FROM_PS 


DFC_SEND_FROM_PS 


FUNCTION: 


OUTPUT : 


Process the record received from presentation services (PS) and determine the 
proper response (positive or negative) or MU (data or signal) that needs to be 
sent to the partner HS via transmission control (TC). If an error is found 
while processing the PS_TO_HS record, the buffer will be freed by this proce- 
dure. 


MU, containing a PS_TO_HS' record (the record type may be SEND_DATA_RECORD, 
CONFIRMED, SEND_ERROR, or REQUEST_TO_SEND); LOCAL.CT_RCV, indication of the 
form-of-response-requested for the last chain received, if the record type is 
CONFIRMED; FSM_CHAIN_RCV_FMP19, indication of the state of the FSM; 
LOCAL.BRACKET_ID, if the record type is SEND_ERROR 


LOCAL .SEND_ERROR_RSP_STATE may be set to indicate that a negative response may 
be sent to the next chain, a response (negative or positive), data or an MU 
contains REQUEST_TO_SEND signal may be sent to TC 


PS initializes the appropriate fields in an MU before sending it to the HS 


Referenced procedures, FSMs, and data structures: 


HS 7 page 6.0-3 

SEND_RSP_MU page 6.1-45 
SEND_FMD_MU page 6.1-4%3 
INITIALIZE _TH_RH page 6.1-38 
DFC_SEND_FSMS page 6.1-27 
FSM_CHAIN_RCV_FMP19 page 6.1-51 
MU page A-29 

LOCAL page 6.0-7 
SIGNAL _RQ_RU SNA Formats 


If MU.PS_TO_HS.BRACKET_ID #% LOCAL.BRACKET_ID then 
Log information concerning the error in the system log. 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous MU. 


Else 


Select based on PS_TO_HS record type: 
When SEND_DATA_RECORD 
Call SEND_FMD_MU(MU) (page 6.1-43) to send the MU. 
When CONFIRMED 
If LOCAL.CT_RCV shows that the last request received indicated RQD2 or RQD3 
(short lock, need to response immediately) then 


Call SEND_RSP_MU( NULL ,NORMAL ,POS ,X'00000000') (page 6.1-45) 


to send a normal-flow positive response. 


Else (long lock, the response is delayed) 


Call buffer manager (FREE_BUFFER, buffer address) to release 


the buffer containing the MU. (Appendix B) 


When SEND_ERROR 
If the state of FSM CHAIN RCV_FMP19 is BETC 
(while between chains, no response may be sent) then 


Set LOCAL.SEND_ERROR_RSP_STATE to NEG_OWED to indicate that a negative 


response should be sent to the next RU received. 


Call buffer manager (FREE_BUFFER, buffer address) to release 


the buffer containing the MU. (Appendix B) 


Else (within the INC state, send -RSP to chain currently being processed) 


Call SEND_RSP_MU( NULL ,NORMAL ,NEG,X'08460000') (page 6.1-45) 


to send a normal-flow negative response. 


When REQUEST_TO_SEND 

Call INITIALIZE_TH_RH(MU) (page 6.1-38) to 

set the TH and RH fields to default values. 

Set the TH and RH fields as described in Figure 6.1-9 on page 6.1-14 for a 
SIGNAL request. 

Set RU to SIGNAL RQ RU (as described under SIG request in SNA Formats). 

Set MU.DCF to the length of (RH + RU). — 

Set LOCAL.COMMON.RQ CODE to SIG. 

Call DFC_SEND_FSMS(MU) (page 6.1-27) to maintain states while sending 
request or response. _ 
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DFC_SEND_FROM_RM 


DFC_SEND_FROM_RM 


FUNCTION: 


INPUT : 


OUTPUT : 


Process records received from the resources manager (RM). This procedure is 
called by the half-session router ("Chapter 6.0. Half-Session"). 


Record from RM (BID_WITHOUT_ATTACH, BIS_REPLY, BIS_RQ, HS_PS CONNECTED, BRACK- 
ET_FREED, RTR_RQ, YIELD_SESSION, or ENCIPHERED_RD2)3 indication that session 
just started, LOCAL.SESSION _JUST_STARTED; primary or secondary half-session 
indicator LOCAL .HALF_SESSIONs; LOCAL .SQN_SEND_CNT .NUMBER3 possibly, an 
HS_PS CONNECTED or BRACKET_FREED record from RM 


The following RUs may be sent: Bid with Attach (carrying BB), Bid with LUSTAT 
(carrying BB), BIS, RTR» or a Yield Session with LUSTAT (carrying CEB). 


In addition, the PS_ID is recorded to identify the PS that is using this HS, 
and an indication that the session just started is also recorded. 


The records received from RM are not MU records. Half-session builds an MU 
record and copies the information from the non-MU record (received from RM) 
and sends it to TC. Limited buffers are used to send normal-flow requests. 
However, half-session uses a permanent buffer for building and sending this MU 
instead of requesting a limited buffer because this MU cannot be held (waiting 
for a limited buffer to become available). However, the limited buffer pool 
needs to be adjusted (decremented by 1) to reflect the correct size of the 


send pacing count. 


Referenced procedures, FSMs, and data structures: 


SEND_FMD_MU page 6.1-43 
DFC_SEND_FSMS page 6.1-27 
INITIALIZE _TH_RH page 6.1-38 
FSM_BSM_FMP19 page 6.1-50 
LOCAL page 6.0-7 
MU page A-29 
BID_WITHOUT_ATTACH page A-17 
BRACKET_FREED page A-18 
ENCIPHERED_RD2 page A-18 
HS_PS_CONNECTED page A-18 
BIS REPLY . page A-12 
BIS ‘RQ page A-12 
YIELD_SESSION page A-19 
RTR_RQ page A-12 


Select based on type of the record from RM: 


When BID_WITHOUT_ATTACH 

Call buffer manager (GET_BUFFER> permanent buffer pool ID» no wait) to 
get a buffer for building an MU (containing the LUSTAT). (Appendix B) 

Create an MU and Call INITIALIZE_TH_RH(MU) to set the TH and RH fields 
to default values (page 6.1-38). 

Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to reduce the size of the limited buffer pool (Appendix B). 

The change amount is a negative value of 1 (see note). 

Set the RH fields as described in Figure 6.1-9 on page 6.1-14¢ for 

an LUSTAT request. 

Set the RU to LUSTAT_RQ RU as described in SNA Formats. 

Call DFC_SEND_FSMS(MU) (page 6.1-27). 


When BIS REPLY 

Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) to 
get a buffer for building an MU (containing the BIS). (Appendix B). 
Create an MU and Call INITIALIZE_TH_RH(MU) to set the TH and RH fields 
to default values. (page 6.1-38). 
Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to reduce the size of the limited buffer pool (Appendix B). 

The change amount is a negative value of 1. 
Set the RH fields as described in Figure 6.1-10 on page 6.1-15 for 

a BIS reply. 
Set the RU to BIS RQ RU as described in SNA Formats. 
Call DFC_SEND_FSMS(MU) (page 6.1-27). 
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DFC_SEND_FROM_RM 


When BIS_RQ 

Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) to 
get a buffer for building an MU (containing the BIS). (Appendix B) 

Create an MU and Call INITIALIZE_TH_RH(MU) to set the TH and RH fields 
to default values. (page 6.1-38). 

Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
_to reduce the size of the limited buffer pool (Appendix B). 

The change amount is a negative value of 1. 

Set the RH fields as described in Figure 6.1-9 on page 6.1-14 for 

a BIS request. 

Set the RU to BIS RQ RU as described in SNA Formats. 

Call DFC_SEND_FSMS(MU) (page 6.1-27). 


When BRACKET_FREED 


For each MU on the PS_TO_HS_Q with a BRACKET_ID equal to BRACKET_ FREED. BRACKET_ID 


Remove the MU from the PS _TO_HS queue. 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
that containing the MU. (Appendix B) 


When HS_PS CONNECTED 

Record PS_ID and BRACKET_ID (from HS PS CONNECTED record) 
in the corresponding LOCAL fields. 

Call FSM_BSM_FMP19 (page 6.1-50) with an INB signal to indicate that 
this half-session is connected to a PS. 

If LOCAL.SESSION_JUST_STARTED is YES then 
(current bracket sequence number was initialized at session start-up) 

Set LOCAL.SESSION_JUST_STARTED to NO. 
Else (set the current bracket sequence number and BB_REGISTER) 


The following calculates the value for the current bracket sequence number and 


the BB_REGISTER before the BB request (to be sent) is received by DFC. 


Set LOCAL.CURRENT_BRACKET_SQN.NUMBER to LOCAL.SQN_SEND_CNT. NUMBER + 1 (taking 


into account that the number wraps at 32767). 

Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to the value of 
LOCAL.HALF_SESSION (PRIISEC). 

Based on the value of LOCAL.HALF_SESSION (PRIISEC) set 
LOCAL.PHS _BB_REGISTER.NUMBER or LOCAL.SHS_BB_REGISTER.NUMBER to 
LOCAL .CURRENT_BRACKET_SQN.NUMBER. 


When RTR_RQ 
Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) to 
get a buffer for building an MU (containing the RTR). (Appendix B) 
Create an MU and Call INITIALIZE_TH_RH(MU) to set the TH and RH fields 
to default values. (page 6.1-38). 
Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to reduce the size of the limited buffer pool (Appendix B). 
The change amount is a negative value of 1. 
Set the RH fields as described in Figure 6.1-9 on page 6.1-14 for 
a RTR request. 
Set the RU to RTR_RQ RU as described in SNA Formats. 
Set LOCAL.COMMON. RQ_CODE to RTR. 
Call DFC_SEND_FSMS(MU) (page 6.1-27). 
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DFC_SEND_FROM_RM 


When YIELD_SESSION 
If LOCAL.SESSION_JUST_STARTED is YES then (session has just started) 
Set LOCAL.SESSION_JUST_STARTED to NO (reset so current bracket SQN will 
be updated on future brackets ) 

Call buffer manager (GET_BUFFER> permanent buffer pool ID», no wait) to 

get a buffer for building an MU (containing the LUSTAT). (Appendix B) 
Create an MU and Call INITIALIZE_TH_RH(MU) to set the TH and RH fields 

to default values. (page 6.1-38). 

Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to reduce the size of the limited buffer pool (Appendix B). 

The change amount is a negative value of 1. 
Set the RH fields as described in Figure 6.1-9 on page 6.1-14 for 

a LUSTAT request. 
Set the RU to LUSTAT RQ RU as described in SNA Formats. 
Set LOCAL .COMMON. RQ_CODE to LUSTAT. 
Call DFC_SEND_FSMS(MU) (page 6.1-27). 


When ENCIPHERED_RD2 
If ENCIPHERED_RD2.SEND_PARM.TYPE is DEALLOCATE_FLUSH then 
Set LOCAL.SESSION_JUST_STARTED to NO. 
Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) to 
get a buffer for building an MU (containing the ENCIPHERED_RD2). (Appendix B) 
Create an MU and set the MU.HEADER to indicate PS_TO_HS, SEND_DATA_RECORD, 
ENCIPHERED_RD2.SEND_PARM.ALLOCATE, ENCIPHERED_RD2.SEND_PARM.FMH, 
ENCIPHERED_RD2.SEND_PARM.TYPE. 
Set RU to ENCIPHERED_RD2.SEND_PARM.DATA as 
described in SNA Formats. 
Call SEND_FMD_MU(MU) (page 6.1-43). 


TRY_TO_RCV_SIGNAL 


FUNCTION: This procedure determines if a REQUEST_TO_SEND record should be sent to PS to 
indicate a SIGNAL has’ been received. This procedure is called by the 
half-session router ("Chapter 6.0. Half-Session"). 


INPUT: None 


OUTPUT: REQUEST_TO_SEND sent to PS if required, indication that a SIGNAL has been 
received (LOCAL.SIG_RECEIVED) altered if stray or current SIGNAL detected 


NOTE : LOCAL.SIG_RECEIVED is set to indicate that a SIGNAL has’ been received before 
this procedure is called. 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_TO_PS page 6.1-30 
SIGNAL_STATUS page 6.1-47 
FSM_BSM_FMP19 page 6.1-50 
REQUEST_TO_SEND page A-10 
LOCAL page 6.0-7 


If the state of FSM_BSM_FMP19 is INB and LOCAL.SIG_ RECEIVED = YES then 
Call SIGNAL_STATUS (page 6.1-47) to determine 
the type of signal received. 
Select, based on the result returned from SIGNAL_STATUS: 
When CURRENT signal 
Call DFC_SEND_TO_PS(NULL, REQUEST_TO_SEND) (page 6.1-30). 
Set LOCAL.SIG_RECEIVED to NO. 


When STRAY signal 
Log error or informational message in the system log. 
Set LOCAL.SIG_ RECEIVED to NO. 


When FUTURE signal 
Do nothing. (The signal will remain in LOCAL until the bracket in 
which it was sent becomes the current bracket. ) 
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DFC_RCV 


FUNCTION: Process MUs received from TC. This procedure is called by TC ("Chapter 6.2. 
Transmission Control"). 


INPUT: MU, containing either a request (normal or expedited) or a response; 
LOCAL.COMMON_RQ_ CODE; irdication whether the alternate code may be used, 
LOCAL .ALTERNATE_CODE 


LOCAL.SIG_RECEIVED is set if SIGNAL is received; the SNF of the SIGNAL is 
saved in LOCAL.SIG_SNF; LOCAL.DIRECTION is set. 


Referenced procedures, FSMs, and data structures: 


DFC_RCV_FSMS page 6.1-25 
FORMAT_ERROR page 6.1-31 
SEND_RSP_MU page 6.1-45 

STRAY_RSP page 6.1-4%8 

TRANSLATE page 6.1-49 

LOCAL page 6.0-7 on 
MU page A-29 ‘a 


Set LOCAL.DIRECTION to RECEIVE state. 
If an alternate code may be used then 
Call TRANSLATE(MU) (page 6.1-49). 
If LOCAL.SENSE_CODE is set to X'00000000' then 
If MU.RH.RU_CTGY is DFC then 
Set the LOCAL.COMMON.RQ_CODE to the MU request code. 
IF LOCAL.COMMON.RQ_CODE is ~(CRV, BIS, LUSTAT, RTR», SIG) then 
Set LOCAL.COMMON.RQ CODE to OTHER. 
Else 
Set LOCAL.COMMON.RQ CODE to OTHER. 
Call FORMAT_ERROR(MU) to perform optional format error checks (page 6.1-31). 
If a format error was found in the MU then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer \ 
containing the erroneous MU (Appendix B). 
Return to the HS router (Chapter 6.0) with LOCAL.SENSE_CODE set 
to a nonzero value. This will cause the session to be deactivated and the 
half-session to be destroyed. 
Else (no format error) 
If request then 
If MU.TH.EFI indicates normal-flow then 
Call DFC_RCV_FSMS(MU) (page 6.1-25). 
Else (expedited-flow SIGNAL request) 
Set LOCAL.SIG_RECEIVED to YES. 
Record the MU sequence number in LOCAL.SIG_SNF (used in determining the | a 
bracket the SIGNAL was intended for). ( 
Call SEND_RSP_MU(MU,EXP ,POS,X'00000000') (page 6.1-45) to \ 
send an expedited positive response to the SIGNAL request immediately. 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the SIGNAL request MU. (Appendix B) 
Else (response ) 
Call STRAY_RSP(MU) to determine if the response is stray (page 6.1-48) 
If the response is not stray then 
Call DFC_RCV_FSMS(MU) (page 6.1-25). 
Else (it is a stray response) 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the stray response MU. (Appendix B) 
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= DFC_RCV_FSMS 


FUNCTION: Enforce data flow control protocols for received requests and responses. 


INPUT: MU, containing either a response or a normal-flow request 


OUTPUT: The request or response is sent’ to RM or PS. Data is recorded (from MU to 
LOCAL) for later use before passing the MU to RM or PS. 


Referenced procedures, FSMs», and data structures: | 
CT_UPDATE page 


6.1-29 

RCV_STATE_ERROR page 6.1-41 

GENERATE_RM_PS_INPUTS page 6.1-36 

SEND_RSP_IF_REQUIRED page 6.1-44 

SEND_RSP_TO_RM_OR_PS page 6.1-4%6 

FSM_RCV_PURGE_FMP19 page 6.1-56 

FSM_QRI_CHAIN_RCV_FMP19 page 6.1-55 

FSM_CHAIN_RCV_FMP19 page 6.1-51 

oar FSM_CHAIN_SEND_FMP19 page 6.1-53 

4 MU page A-29 

—" LOCAL page 6.0-7 


Call RCV_STATE_ERROR(MU) (page 6.1-41). These checks are optional. 
If a state error is found then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous MU (Appendix B). 
Else (no state error) 
Record MU header, header type», MU.DCF, MU.RH in LOCAL fields. 
If RU is present in the MU then 
Save the addressability to the MU.RU in LOCAL fields. 
Select anyorder: 
ae When normal-flow request 
< \ If LOCAL.RQD_REQUIRED_ON_CEB = NO then 
— Increment LOCAL .NORMAL_FLOW_RQ COUNT by 1. 
If LOCAL .NORMAL_FLOW_RQ_COUNT exceeds 2**14 then 
set LOCAL.RQD_REQUIRED_ON_CEB to YES. 
Call CT_UPDATE(MU, LOCAL.CT_RCV) (page 6.1-29). 
If BBI = BB then 
If half-session is in send state then 
If primary half-session then 
Set LOCAL.PHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_SEND.SNF.BRACKET_STARTED_BY to PRI. 
Else 
Set LOCAL.SHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
ea Set LOCAL.CT_SEND.SNF.BRACKET_STARTED_BY to SEC. 
C Else (in receive state) 
/ If primary half-session then 
Set LOCAL.SHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_RCV.SNF.BRACKET_STARTED_BY to SEC. 
Else 
Set LOCAL.PHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_RCV.SNF.BRACKET_STARTED_BY to PRI. 
If the state of FSM_RCV_PURGE_FMP19 4 PURGE then 
Call GENERATE_RM_PS_INPUTS(MU) (page 6.1-36). 
Else 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the MU. (Appendix B) 


Call FSM_RCV_PURGE_FMP19(MU) to maintain a purging state for received 
BB chains (page 6.1-56). 
If the state of FSM_CHAIN SEND _FMP19 = PEND _RCV_REPLY then 
Call FSM_CHAIN_SEND_FMP19(MU, NOT_SPECIFIED) (page 6.1-53). 
If BCI = BC then 
Call FSM_CHAIN_RCV_FMP19(MU, BEGIN_CHAIN) (page 6.1-51). 
If ECI = EC then 
7 Call FSM_CHAIN_RCV_FMP19(MU, END CHAIN) (page 6.1-51). 
' Call FSM_QRI_CHAIN_RCV_FMP19(MU) (page 6.1-55). 
- Call SEND_RSP_IF_REQUIRED(MU) (page 6.1-44). 
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When normal-flow response 
Call CT_UPDATE(MU, LOCAL.CT_SEND) (page 6.1-29). 
Call SEND_RSP_TO_RM_OR_PS(MU) (page 6.1-46). 
Call FSM_CHAIN_SEND_FMP19(MU, NOT_SPECIFIED) (page 6.1-53). 


When expedited-flow response (1.e., a positive RSPI[SIG]) 


Set LOCAL.SIG_RQ_OUTSTANDING to NO. 
Call SEND_RSP_TO_RM_OR_PS(MU) (page 6.1-46). 
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DFC_SEND_FSMS 
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FUNCTION: Maintain states by invoking the appropriate FSM while sending requests and 
responses. 


INPUT: MU containing request or response; alternate code allowed indicator, 
LOCAL .ALTERNATE_CODE 


OUTPUT : Reques t/response to TC; possible update oof the following fields: 
LOCAL.DIRECTION; LOCAL.SIG_RQ_OUTSTANDING; sequence number for request or 
response, LOCAL.SQN_SEND_CNT 


Referenced procedures, FSMs, and data structures: 


SEND_MU page 6.2-20 

CT_UPDATE page 6.1-29 

TRANSLATE page 6.1-49 

FSM_CHAIN_RCV_FMP19 page 6.1-51 

FSM_CHAIN_SEND_FMP19 page 6.1-53 
aa MU page A-29 
C LOCAL page 6.0-7 


Set LOCAL.DIRECTION to SEND. 
Calculate the proper sequence number to use in the request or response and 
place the value in MU.TH.SNF. 
Select anyorder: 
When normal-flow request 
If LOCAL.RQD_REQUIRED_ON_CEB = NO then 
Increment LOCAL.NORMAL_FLOW_RQ_COUNT by 1. 
If LOCAL.NORMAL_FLOW_RQ_COUNT exceeds 2**14 then 
set LOCAL.RQD_REQUIRED_ON_CEB to YES. 
ae Call CT_UPDATE(MU, LOCAL.CT_SEND) (page 6.1-29). 
| If CEBI is CEB then 
If a definite response is required on a RQE1 request then 
Change RQE1 to RQD1. 
(This allows stray SIGNALs and responses to be accurately recognized. 
If RQD request then 
Reset LOCAL.RQD_REQUIRED_ON_CEB to No and LOCAL.NORMAL_FLOW_RQ_COUNT to 0. 
If LOCAL.FSM_CHAIN_RCV_FMP19 is in PEND_SEND_REPLY state then 
Call FSM_CHAIN_RCV_FMP19(MU, NOT_SPECIFIED) (page 6.1-51). 
(This request is an implicit response). 
If BBI is BB then 
If half-session is in send state then 
If primary half-session then 


forme Set LOCAL .PHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
@ Set LOCAL.CT_SEND.SNF.BRACKET_STARTED_BY to PRI. 
re Else 


Set LOCAL.SHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_SEND.SNF.BRACKET_STARTED_BY to SEC. 
Else (in receive state) 
If primary half-session then 
Set LOCAL.SHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_RCV.SNF.BRACKET_STARTED_BY to SEC. 
Else 
Set LOCAL.PHS_BB_REGISTER.NUMBER to MU.TH.SNF.NUMBER. 
Set LOCAL.CT_RCV.SNF.BRACKET_STARTED_BY to PRI. 
If BCI is BC then 
Call FSM_CHAIN_SEND_FMP19(MU, BEGIN_CHAIN) (page 6.1-53). 
If ECI is EC then 
Call FSM_CHAIN_SEND_FMP19(MU, END_CHAIN) (page 6.1-53). 
When normal-flow response 
Call CT_UPDATE(MU,LOCAL.CT_RCV) (page 6.1-29). 
Call FSM_CHAIN_RCV_FMP19(MU, NOT_SPECIFIED) (page 6.1-51). 


When expedited-flow request (1.e., a SIGNAL request) 
Set the LOCAL.SIG_RQ OUTSTANDING to YES. 


C) If an alternate code may be used then 
Call TRANSLATE(MU) (page 6.1-49). 


Call SEND_MU(MU, LOCAL.COMMON_CB) (page 6.2-20). 
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LOW-LEVEL PROCEDURES (IN ALPHABETICAL ORDER) | 2 


C) 


BUILD_HS_TO_PS_HEADER 


FUNCTION: Fill in MU.HS_TO_PS_HEADER based on the contents of MU.RH. 


INPUT: MU containing data that needs to be passed to PS and information about the 
type of HS_TO_PS header that needs to be built 
OUTPUT: MU fields may be set properly to reflect the contents of MU.RH 
Referenced procedures, FSMs, and data structures: ( 
MU - page A-29 


Set MU.HEADER_TYPE to HS_TO PS. 
Set MU.HS_TO_PS.FMH to NO. 


If FI = FMH then 
If RU_CTGY = FMD (FMD request) then 
Set MU.HS_TO_PS.FMH to YES. 
Else (LUSTAT request) 
Set MU.DCF to the length of MU.RH. 
If ECI = EC then 
Select in any order 


When (RQE1 and CDI=CD) 
Set MU. HS_TO_PS.TYPE to PREPARE_TO_RCV_FLUSH. - 
When (RQ*1l and CEBI=CEB) ee 


Set MU.HS_TO_PS.TYPE to DEALLOCATE_FLUSH. 
When (RQD213 and CDI=-CD and CEBI=-CEB) 
Set MU.HS_TO_PS.TYPE to CONFIRM. 
When (RQ*213 and CDI=CD) 
- Set MU.HS_TO_PS.TYPE to PREPARE_TO_RCV_CONFIRM. 
When (RQD213 and CEBI=CEB) 
Set MU.HS_TO_PS.TYPE to DEALLOCATE_CONFIRM. 
Else 
Set MU.HS_TO_PS.TYPE to NOT_END_OF_DATA. 
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CT_UPDATE 


CT_UPDATE 


FUNCTION: Record information about the last chain sent or received. This is done by 
updating the correlation table entry (CT). 


INPUT: MU, containing the information to save about a sent or received chain; CT may 
be updated, either CT_SEND or CT_RCV; 


OUTPUT: Information from the input MU added to the information that was saved from the 
earlier RUs of the chain, this information is saved in the input correlation 
table (CT_RCV or CT_SEND) 


LOCAL.COMMON.RQ_CODE is set properly before this procedure is called. 


Referenced procedures, FSMs, and data structures: 
CT page 6.0-8 
MU page A-29 


If MU contains a request then 
If BCI = BC then 
Record the following information relating to the chain in the input 
correlation table (CT): 
Set the ENTRY_PRESENT to YES. 
Set SNF to MU.SNF3 
Set NEG_RSP_SENSE to X'00000000'. 
Set RU_CTGY to MU.RU_CTGY. 
Save the value of DRII, DR2I, ERI, QRI, BBI, ~CEB, -CD in the 
CT.RH fields. 
If the RU_CTGY = DFC then 
Record the MU request code in CT.RQ_CODE. 
Else 
Set CT.RQ_CODE to OTHER. 
If MU.ECI = EC then 
Save the value of DR1I, DR2I, ERI, CEBI and CDI in the CT.RH fields. 
Else (MU contains a response) 
If MU.SDI = SD then 
Record that an error was found for this chain by saving the sense data from 
the response in CT.NEG_RSP_SENSE. 
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DFC_SEND_TO_PS 


Send a record to PS. This procedure may locally create the record to send; 
depending on record type. 


MU address (may be NULL if record type -= MU); record type to specify the type 
of record to send; the bracket ID that identifies this conversation, 
LOCAL .BRACKET_ID 


Appropriate record or an MU is sent to PS. 


Referenced procedures, FSMs> and data structures: | 


HS page 6.0-3 
PS page 5.0-8 
MU page A-29 
LOCAL ' page 6.0-7 
CONFIRMED page A-10 
RECEIVE _ERROR page A-10 
REQUEST_TO_SEND page A-10 A 
RSP_TO_REQUEST_TO_SEND : page A-11 ‘a 
; Sec ee 
If the input record type is MU then 
Set the MU.HS_TO_PS.BRACKET_ID to LOCAL.BRACKET_ID. 
Else (record type -= MU) 
Create the requested record type (CONFIRMED, REQUEST_TO_SEND, 
. RSP_TO_REQUEST_TO_SEND, or RECEIVE_ERROR) with BRACKET_ID 
set to LOCAL.BRACKET_ID. 
Send the record to the PS that is using this session. 
If the PS is no longer receiving then 
If the record is an MU then 
Call buffer manager (FREE_BUFFER, buffer address) to release the re 
buffer containing the MU. (Appendix B) ; 
Else z 
Destroy the record. a 
( * 
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FORMAT_ERROR 


FORMAT_ERROR 


FUNCTION: Perform format checks on all requests and responses for LU-LU session. These 
checks are optional. If an error is detected, the LOCAL.SENSE_CODE is set to 
the appropriate sense data. None» some, or all of these checks may be done. 


MU, containing a request or response 


TRUE for format error detected; otherwise, FALSE 


Referenced procedures, FSMs,», and data structures: 


FORMAT_ERROR_RQ_FMD page 6.1-34% 
FORMAT_ERROR_RQ_DFC page 6.1-33 
FORMAT_ERROR_NORM_RSP page 6.1-32 
FORMAT_ERROR_EXP_RSP page 6.1-32 
MU page A-29 

LOCAL page 6.0-7 


Set return code to FALSE. 
Select based on one of the following conditions: 
When request 
If RU_CTGY = FMD 
Call FORMAT_ERROR_RQ_FMD(MU) (page 6.1-34). 
Else (When request with RU category of DFC) 
Call FORMAT_ERROR_RQ_DFC(MU) (page 6.1-33). 


When normal-flow response 
Call FORMAT_ERROR_NORM_RSP(MU) (page 6.1-32). 


When expedited-flow response 
Call FORMAT_ERROR_EXP_RSP(MU) (page 6.1-32). 


(LOCAL.SENSE_CODE is set with the sense data indicating the type of error 
if an error is found by any of the above called procedures. ) 
If LOCAL.SENSE_CODE # X'0000 0000‘ then 
Set the return code to TRUE. (Format error found. ) 


Pass the return code to the calling procedure. 
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FORMAT_ERROR_EXP_RSP 


FORMAT_ERROR_EXP_RSP 


INPUT: MU , containing an expedited-flow response 


For an error, LOCAL.SENSE_CODE is set to the appropriate sense data. 


OUTPUT : 


Referenced procedures, FSMs, and data structures: 
MU page A-29 
LOCAL page 6.0-7 


Select, in order, based on fields in the MU: 
| When RU_CTGY # DFC 
Set LOCAL.SENSE_CODE to X'40110000'. 
When FI = ~FMH 
Set LOCAL.SENSE_CODE to X‘'400F0000'. 
When (SDI = SD and RTI = POS) or (SDI = -SD and RTI = NEG) 
Set LOCAL.SENSE_CODE to X‘'40130000'. 
When BCI = -BC or ECI = -EC : 
Set LOCAL.SENSE_CODE to X‘'400B0000'. 
When QRI = QR 
Set LOCAL.SENSE_CODE to X'40150000'. 
When RQ_CODE * SIG 
Set LOCAL.SENSE_CODE to X'40120000'. 
When RTI = NEG (-RSP to expedited request ) 
Set LOCAL.SENSE_CODE to the sense data in the MU (first 4 bytes). 


FORMAT_ERROR_NORM_RSP 


FUNCTION: Perform format checks on normal-flow responses. These checks are optional. 


INPUT : MU, containing a normal-flow response 


OUTPUT: » For an error, LOCAL.SENSE_CODE is set to the appropriate sense data. 


Referenced procedures, FSMs, and data structures: 
MU | page A-29 
LOCAL page 6.0-7 


Select, in order, based on fields in the MU: 

When BCI = -BC or ECI = -EC 
Set LOCAL.SENSE_CODE to X‘'400B0000°. 

When (SDI = SD and RTI = POS) or (SDI = -SD and RTI = NEG) 
Set LOCAL.SENSE_CODE to X'40130000'. 

When RU_CTGY = DFC and FI = -FMH 
Set LOCAL.SENSE_CODE to X‘'400F0000'. 

When RU_CTGY = FMD, RTI = POS, and FI = FMH 
Set LOCAL.SENSE_CODE to X'400OFO000'. 

When RTI = NEG (negative response) and the sense data in the MU (first 4 bytes) 

is not (X'08130000', X'08140000', X'08190000', X'084¢60000', or X'088B0000' ) 

‘Set LOCAL.SENSE_CODE to the response sense data. 


6.1-32 SNA LU 6.2 Reference: Peer Protocols 


FUNCTION: Perform format checks on expedited-flow responses. These checks are optional. 


C) 


FORMAT_ERROR_RQ_DFC 
FORMAT_ERROR_RQ_DFC 
FUNCTION: Perform format checks for data flow control (DFC) requests. These checks are 


optional. 


INPUT: MU, containing DFC request 


OUTPUT: If error, LOCAL.SENSE_CODE is set to the appropriate sense data 


Referenced procedures, FSMs,» and data structures: 


FORMAT_ERROR_RQ_FMD page 6.1-34 
MU page A-29 

LOCAL page 6.0-7 
LUSTAT RQ RU SNA Formats 
SIGNAL_RQ_RU SNA Formats 


Select, in the following order, based on one of the following conditions: 
When normal-flow and the request code is not (BIS, LUSTAT, or RTR) 
. Set LOCAL.SENSE_CODE to X'10030000'. 
| When expedited-flow and request code is not SIGNAL 
oe : Set LOCAL.SENSE_CODE to X'10030000'. 
: When expedited-flow and the request code is SIGNAL and 
(MU.DCF is too short for SIGNAL or , 
SIGNAL_CODE in the SIGNAL_RQ_RU does not match the LU 6.2 defined format) 
Set LOCAL.SENSE_CODE to X'10050000'. 
When FI # FMH 
Set LOCAL.SENSE_CODE to X'4GOOFOOOO’. 
When BCI = -BC or ECI = -~EC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When CSI = CODE1 
Set LOCAL.SENSE_CODE to X'40100000'. 
When EDI = ED 
ee Set LOCAL.SENSE_CODE to X'40160000'. 
eG When PDI = PD 
a Set LOCAL.SENSE_CODE to X'40170000'. 
Otherwise 
If LUSTAT request then 
If MU.DCF is too long for a LUSTAT request MU and 
MU.RU contains LUSTAT_RQ_RU.STATUS_ VALUE then 
Call FORMAT_ERROR_RQ_FMD(MU) (page 6.1-34). 
(LOCAL .SENSE_CODE set by called procedure if an error is detected. ) 
Else (too short for LUSTAT) 
Set LOCAL.SENSE_CODE to X‘'10050000'. 
Else (-LUSTAT request) 
Select, in order, based on one of the following: 
| When (BIS request with RQDZ/IRQD3 set) or 
\ ! (-BIS request with -RQD1 set) 
ee Set LOCAL.SENSE_CODE to X'40140000'. 
When QRI = QR 
Set LOCAL.SENSE_CODE to X'40150000'. 
When BBI = BB or EBI = EB or CEBI = CEB 
' Set LOCAL.SENSE_CODE to xX'400C0000'. 
When CDI = CD 
Set LOCAL.SENSE_CODE to X'40090000'. 
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6.1-34 


OUTPUT : 


NOTES: 


FORMAT_ERROR_RQ_FMD 


INPUT: MU, containing FMD request 


0). 


LOCAL.ALTERNATE_CODE is set before this procedure is called. 


Record FMH type (from MU.RU) for later use (see note 1). 
Select, in order, based on the TH or RH settings in the MU: 


When expedited-flow 
Set LOCAL.SENSE_ CODE to X'40110000'. 


When the form-of-response-requested is not RQE or RQD 
Set LOCAL.SENSE_ CODE to X'40140000'. 


When the form-of-response-requested is RQD and ECI = ~EC 
Set LOCAL.SENSE_CODE to X'‘'40070000'. 


When BBI = BB and BCI = -BC 
Set LOCAL.SENSE_CODE to *'40030000'. 


FMH field is only 7 bits and the concatenation bit is a 


FUNCTION: Perform format checks on FM data (FMD) requests. These checks are optional. 


For an error, LOCAL.SENSE_CODE is set to the appropriate sense data. 


reserved bit (set to 


page A-29 
page 6.0-7 


When BBI = BB, RU CTGY = FMD, and ~(FI = FMH and FM header type = ATTACH_FMH) 


Set LOCAL.SENSE_CODE to X'40030000'. 


When CSI = CODE1 and alternate code will not be used 
Set LOCAL.SENSE_CODE to X'40100000'. 


When EBI = EB (EB not allowed with FM profile 19.) 
Set LOCAL.SENSE_CODE to X'40040000'. 


When CDI = CD and ECI = -EC (CD allowed only with EC) 
Set LOCAL.SENSE_CODE to X‘40090000'. 


When CDI = CD and form-of-response-requested is RQD1 (CD may not: be sent with RQD1) 


Set LOCAL.SENSE_CODE to X'40090000'. 


When CEBI = CEB and ECI = -EC 
Set LOCAL.SENSE_CODE to X'40040000'. 


When BCI = BC and (( the request is received from the bidder with BBI=BB and QRI=-QR) 


or (the request is received from the first speaker with BBI = BB or QRI = QR)) 


Set LOCAL.SENSE_CODE to X'4¢0180000'. 


When CEBI = CEB and CDI = CD (Transaction program verbs cannot generate this combination. ) 


Set LOCAL.SENSE_CODE to X‘'4¢0090000'. 


When CEBI = CEB and form-of-response-requested is RQE2 or RQE3 


(DEALLOCATE-CONFIRM (CEB,RQD2/3) and DEALLOCATE-FLUSH (CEB,RQE1) are valid) 


Set LOCAL.SENSE_CODE to X'40040000'. 


When CEBI = -CEB, CDI = -CD, ECI = EC, and form-of-response-requested is RQE 


Set LOCAL.SENSE_CODE to X'40190000'. 


When FI = FMH, CEBI = -CEB, and form-of-response-requested is RQD1 


Set LOCAL.SENSE_CODE to X'40190000'. 


When BBI = BB, CEBI = CEB, form-of-response-requested is RQE1, and this 


half-session is the first speaker (BB, CEB, RQE1 not allowed from the bidder) 


Set LOCAL.SENSE_CODE to X'40040000'. 
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When FI = FMH, CEBI = CEB, FM header type = ERROR_FMH», and ERI = ER 
Set LOCAL.SENSE_CODE to X'40060000'. 


When FI = FMH, RU_CTGY = FMD, and FM header type is not (ATTACH_FMH or ERROR_FMH) 
If FM header type is SECURITY_FMH then 
If (ECI = EC and CEBI = -CEB) or BCI = BC then 
Set LOCAL.SENSE_CODE to X'O80F6051'. 
Else 
Set LOCAL.SENSE_CODE to X‘100846001'. 
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GENERATE_RM_PS_INPUTS 


FUNCTION: Generate the appropriate records for RM and PS based on the passed MU's con- 
tent. 


INPUT: MU containing normal-flow request; information about the last request sent; 
LOCAL.CT_SEND; possibly in addition, a BID_RSP or an RTR_RSP record from RM 


OUTPUT: Appropriate records sent to RM and PS, LOCAL.CURRENT_BRACKET_SQN, ID of the PS 
connected to this HS 


Referenced procedures, FSMs,» and data structures: 


DFC_SEND_TO_PS page 6.1-30 

RM page 3-19 
PROCESS_RU_DATA page 6.1-40 

OK_TO_REPLY page 6.1-39 
FSM_RCV_PURGE_FMP19 page 6.1-56 

BID page A-11 

BID_RSP page A-1l1 

BIS_RQ page A-12 — 
BIS REPLY page A-12 Me aad 
RTR_RQ page A-l2 = ~ 
BRACKET_FREED page A-18 

RTR_RSP page A-13 

MU page A-29 

LOCAL page 6.0-7 


Select, in order, based on one of the following conditions: 
When BBI = BB 
Create a BID record with HS_ID set to LOCAL.HS_ID and send it to RM. 
Receive the BID_RSP from RM. 
Check the RM_TO_HS_Q to see if a BIS, RTR» or BRACKET_FREED record has 


been received from RM. If so, send the record now (a BID race may . SRS 
have occurred). 


If a positive Bid response is received then 
If RU category is FMD then 
Call PROCESS_RU_DATA(MU) (page 6.1-40). 
Else 
Set LOCAL.BB_RSP_STATE to POS_OWED to record that a positive response is owed. 
Call buffer manager (FREE_BUFFER, buffer address) te release the buffer 
containing the received MU (Appendix B). 
Else (negative response to Bid) 
Call FSM_RCV_PURGE_FMP19 SIGNAL( PURGE) (page 6.1-56) to cause the 
remainder of this BB chain to be purged. 
Set LOCAL.BB_RSP_STATE to NEG_OWED to record that a negative response is owed. — 
Set LOCAL.BB_RSP_SENSE to BID_RSP.SENSE_CODE to record the sense data. ( 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing received MU (Appendix B). 
Destroy the BID_RSP record from RM. 


When RU_CTGY is DFC and request code is BIS 
If the form-of-response-requested is RQE1 then 
Create a BIS _RQ record with HS_ID set to LOCAL.HS_ID and send it to RM. 
Else (RQE2|3) 
Create a BIS_REPLY record with HS_ID set to LOCAL.HS_ID and send it to RM. 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing received MU (Appendix B). 
When RU_CTGY is DFC and request code is RTR 
Create an RTR_RQ record with HS_ID set to LOCAL.HS_ID and send it to RM. 
Receive RTR_RSP from RM. 
If a positive RTR response is received then 
Set LOCAL.RTR_RSP_STATE to POS_OWED to record that a positive response is owed. 
Else (negative response to RTR) 
Set LOCAL.RTR_RSP_STATE to NEG_OWED to record that a negative response is owed. 
Set LOCAL.RTR_RSP_SENSE to RTR_RSP.SENSE_CODE to record the sense data. 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer : 
containing received MU (Appendix B). * 
Destroy the RTR_RSP record. a 
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Otherwise 
Call OK_TO_REPLY(MU) (page 6.1-39) to determine if MU is a reply. 
If MU is a reply and the last chain sent was RQE2 or RQE3 then 
Call DFC_SEND_TO_PS(MU pointer, CONFIRMED) (page 6.1-30). 


Call PROCESS_RU_DATA(MU) (page 6.1-40). 
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INITIALIZE_TH_RH 


FUNCTION: Initialize the TH and RH fields of an MU record. 


INPUT: A newly created MU 


OUTPUT: Initialized RH and selected TH bits, LOCAL.COMMON.RQ_CODE 


Referenced procedures, FSMs, and data structures: 
MU page A-29 


Set default values for the TH fields in the MU as follows: 
EFL to normal-flow, SNF.SQN to 0, BBIUI to BBIU, and EBIUI to EBIU. 


Set default values for the RH fields in the MU as follows: 
RRI to RQ, RU_CTGY to FMD, FI to -FMH, SDI to ~SD, RTI to POS, 
BCI to -BC, ECI to -EC, RQE1, RLWI to -RLW, QRI to -QR,> 
PI to -PAC, BBI to -BB, EBI to -EB, CDI to -CD, 
CSI to CODEO, EDI to -ED, PDI to -PD, CEBI to -~CEB a 


Set LOCAL.COMMON.RQ_CODE to OTHER. 


INVALID_SENSE_CODE 


FUNCTION: Determine if sense data on negative response is valid. 


INPUT: MU containing negative response; information about the last chain sent, 
LOCAL.CT_SEND; first-speaker indicator, LOCAL.FIRST_SPEAKER 


OUTPUT: TRUE for invalid sense data; otherwise, FALSE 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
MU page A-29 
LOCAL page 6.0-7 
If this is a response to a BB chain then 
If this half-session is first speaker then 
If the sense data in the response is not X'08460000' or X'088B0000' then Se 
Return with a value of TRUE (invalid sense data). ‘ 


Else (bidder) 
If the sense data in the response is not X‘'08130000', X'08140000', 
or X'088B0000' then 
Return with a value of TRUE (invalid sense data). 


Else (response to -BB chain) 
If response to RTR then 
If the sense data in the response is not X'08190000' then 
Return with a value of TRUE (invalid sense data). 
Else (not response to RTR) 
If response to BIS then (negative response to BIS not allowed) 
Return with a value of TRUE (invalid sense data). 
Else 
If the sense data in the response is not X'08460000' then 
Return with a value of TRUE (invalid sense data). 


Return with a value of FALSE (valid sense data). 
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C 


FUNCTION: 


INPUT : 


OUTPUT : 


OK_TO_REPLY 


Determine whether or not a request is a valid reply. A reply is a request 
sent (or received) after receiving (or sending) an (RQE,CD) request. 


MU, containing a normal-f low request; LOCAL .DIRECTION; 
LOCAL .CURRENT_BRACKET_SQN; information about the last chain sent, 
LOCAL .CT_SEND 


TRUE if valid reply; otherwise, FALSE 


Referenced procedures, FSMs, and data structures: 


LOCAL page 6.0-7 
MU page A-29 

FSM_CHAIN_RCV_FMP19 page 6.1-51 
FSM_CHAIN_SEND_FMP19 page 6.1-53 


Select, in order, based on one of the following conditions: 


Return with a value of FALSE (not a valid reply). 


C When the request is BIS or RTR 


When the request indicates BBI = BB or BCI = -BC 
Return with a value of FALSE (not a valid reply). 


When (sending and the state of FSM_CHAIN_RCV_FMP19 is not PEND_SEND_REPLY) or 
(receiving and the state of FSM_CHAIN_SEND_FMP19 is not PEND_RCV_REPLY ) 
{page 6.1-51 and page 6.1-53) 

Return with a value of FALSE (not a valid reply). 


When receiving and the state of FSM_BSM_FMP19 (page 6.1-50) is INB and the 
last chain sent carried BB and LOCAL.CURRENT_BRACKET_SQN # the SNF of that chain 
Return with a value of FALSE (not a valid reply). 


} 


KY Otherwise 
y Return with a value of TRUE (valid reply). 


Chapter 6.1. Data Flow Control 6.1-39 


PROCESS_RU_DATA 


PROCESS _RU_DATA 


FUNCTION: Process an RU and,» based on the content of the RU, send the appropriate 
records to RM and PS. 


INPUT: MU containing a normal-f low request; LOCAL .SHS_BB_REGISTER; 
LOCAL.PHS_BB_REGISTER; LOCAL.HALF_SESSION (indication that half-session is 
primary or secondary); possibly in addition, an HS_PS CONNECTED record 
received from RM. 


OUTPUT: Appropriate records sent to RM or PS; if an FMH-5S(Attach) is present; 
LOCAL .CURRENT_BRACKET_SQN is set. 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_TO_PS page 6.1-30 

FSM_BSM_FMP19 page 6.1-50 

BID_RSP page A-1l 

HS_PS_ CONNECTED page A-18 
BUILD_HS_TO_PS_HEADER page 6.1-28 a 
MU page A-29 ( 
LOCAL page 6.0-7 Ne ay 


IF FI = FMH and RU_CTGY = FMD then 
Select, based on FMH type in RU: 
When X'05' (Attach) 
Call BUILD_HS_TO_PS_HEADER(MU) (page 6.1-28). 
Set MU.HS _TO_RM.HS_ID to LOCAL.HS_ID. 
Send the request MU to RM. 
Receive the HS_PS_CONNECTED record from RM. 
Save the PS_ID and the BRACKET_ID from the HS_TO_PS_CONNECTED record 
in the corresponding LOCAL fields. 
Call FSM_BSM_FMP19 with an INB signal (page 6.1-50) 
to indicate that the HS is connected to a PS. ae 
Destroy the HS_PS_CONNECTED record from RM. | 
If primary half-session then - 
Set LOCAL.CURRENT_BRACKET_SQN to LOCAL.SHS_BB_REGISTER. 
Else 
Set LOCAL.CURRENT_BRACKET_SQN to LOCAL.PHS_BB_REGISTER. 
When X'07' (Error Description) 
Call BUILD_HS_TO_PS_HEADER(MU) (page 6.1-28). 
Call DFC_SEND_TO_PS(MU pointer, MU) (page 6.1-30). 
When X'OC' (Security) 
Build an HS_TO_PS MU header. 
Set MU.HS_TO_RM.HS_ID to LOCAL.HS_ID. 
Send the record to RM. ra 


Else 
If ECI = EC or MU.RU is present then ( 
Call BUILD_HS_TO_PS_HEADER(MU) (page 6.1-28). 
Call DFC_SEND_TO_PS(MU pointer, MU) (page 6.1-30). 
Else 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the MU. (Appendix B) 
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RCV_STATE_ERROR 


FUNCTION: Perform state error checking on received requests and responses. The types of 
errors found here are protocol violations by the sender of the request or 
response. These checks are optional. None, some, or all of the checks may be 
made. 


INPUT : MU containing request or response; indication of whether a response to a SIG- 
NAL is expected, LOCAL.SIG_RQ OUTSTANDING 


OUTPUT: TRUE if a state error was’ encountered; otherwise, FALSE. If TRUE; 
LOCAL .SENSE_CODE is set to the appropriate sense data 


Referenced procedures, FSMs, and data structures: 


INVALID_SENSE_CODE page 6.1-38 
FSM_BSM_FMP19 page 6.1-50 
FSM_QRI_CHAIN_RCV_FMP19 page 6.1-55 
FSM_CHAIN_RCV_FMP19 page 6.1-51 
FSM_CHAIN_SEND_FMP19 page 6.1-53 
MU page A-29 
LOCAL page 6.0-7 


Select based on EFI and RRI: 
When normal-flow request 
Select, in order, based on the following conditions: 
When a (RQE,BB,CEB) chain is received from the bidder 
Set LOCAL.SENSE_CODE to X'40040000' ((RQE,BB,CEB) not allowed from bidder). 
Return with a value of TRUE. 


When executing FSM_BSM_FMP19(MU) (page 6.1-50), 
FSM_CHAIN_RCV_FMP19(MU) (page 6.1-51), or 
FSM_QRI_CHAIN_RCV_FMP19(MU) (page 6.1-55) would cause a state 
check (>) condition 
Execute the corresponding output code in the first FSM that encountered 
a state-check condition (to set LOCAL.SENSE_CODE }). 
Return with a value of TRUE. 


When normal-flow response 
Select based on the following conditions: 

When RU category of the response # RU category of the request 
Set LOCAL.SENSE_CODE to X'40110000'. 
Return with a value of TRUE. 

When RU category of the response = DFC and 

the request code of the response # the request code of the request 

Set LOCAL.SENSE_CODE to X'40120000'. 
Return with a value of TRUE. 

When the QRI field of the response * the QRI of the request 
Set LOCAL.SENSE_CODE to X'40210000'. 
Return with a value of TRUE. 

When response is negative and contains an invalid sense data 

(call INVALID _SENSE_CODE(MU) [page 6.1-38]) 

Set LOCAL.SENSE_CODE to X'20120000'. 
Return with a value of TRUE. 

When executing FSM_CHAIN_SEND_FMP19(MU) (page 6.1-53). 

would cause a state-check (>) condition 
Execute the corresponding output code (to set LOCAL.SENSE_CODE ). 
Return with a value of TRUE. 


When expedited-flow response (1.e., a positive response to SIGNAL) 
If a SIGNAL request is not outstanding (not waiting for response to SIGNAL) then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 
Return with a value of TRUE. 


Return with a value of FALSE. 
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REPLY_TO_BID 


FUNCTION: Determine if a normal-flow request is a reply toa BID request. A reply is a 


request sent (or received) immediately after 


receiving (or sending) a request 


carrying (RQE,CD)}. A reply implies a positive response to the (RQE,CD) 


request. 


INPUT: MU containing a normal-flow request; information about the last chain sent; 


LOCAL ..CT_SEND 


OUTPUT: TRUE if MU is reply to a bid; FALSE, otherwise 


Referenced procedures, FSMs,» and data structures: 


OK_TO_REPLY page 6.1-39 
MU page A-29 
LOCAL page 6.0-7 
FSM_BSM_FMP19 page 6.1-50 
Call OK_TO_REPLY(MU) (page 6.1-39). 
If it is OK to reply and _ 
the state of FSM_BSM_FMP19 = BETB (page 6.1-50) and K 


the last chain sent was a BB chain then 
Return with a value of TRUE. 
Else 
Return with a value of FALSE. 


SEND_BID_POS_RSP 


FUNCTION: Send RM a positive response to a Bid, and receive 
that will result in this half-session being connected to a PS. 


INPUT: MU; information about the last chain sent, LOCAL.CT_SEND 


OUTPUT : BID_POS_RSP sent to RM, LOCAL.CURRENT_BRACKET_SQN 


Referenced procedures, FSMs, and data structures: 


the HS_PS_CONNECTED record 


FSM_BSM_FMP19 page 6.1-50 

MU page A-29 
HS_PS_CONNECTED page A-18 we 
LOCAL page 6.0-7 . 


Create a positive BID_RSP record with HS_ID set to LOCAL.HS_IS and SENSE_CODE set to 0. 
Send the record to RM. 


Receive the HS_PS_CONNECTED record associated with the BID_POS_RSP from RM. 
Save the PS_ID and the BRACKET_ID from the HS_TO_PS_CONNECTED in the 
corresponding LOCAL fields. 
Call FSM_BSM_FMP19 with an INB signal (page 6.1-50) 
to indicate that the HS is connected to a PS. 
Destroy the HS_PS_ CONNECTED record from RM. 


Set LOCAL.CURRENT_BRACKET_SQN to the SNF of the last chain sent. 
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SEND_FMD_MU 


FUNCTION: Send an MU according to passed instructions. 


INPUT: MU, containing a PS_TO_HS record (it informs this procedure how to set the 


BBI, FI, BETC, BCI, ECI, ERI, DR1I, and DR2I bits in the RH) 


OUTPUT : The MU is created and initialized; MU.RH bits, LOCAL.COMMON.RQ_CODE, MU.RU are 


set (according to the PS_TO_HS record); and the MU is sent to PS, BETC 


Referenced procedures, FSMs, and data structures: 


INITIALIZE _TH_RH page 6.1-38 
DFC_SEND_FSMS page 6.1-27 
LOCAL - page 6.0-7 
LUSTAT_RQ_RU SNA Formats 
MU page A-29 


Call INITIALIZE_TH_RH(MU) to set the TH and RH fields of the input MU 
to default values. 
If input MU contains an FMH header then 


If 


If 


If 


Set MU.RH.FI to FMH. 
starting a new chain (the last RU sent indicated EC) then 
Set MU.RH.BCI to BC and LOCAL.BETC to NO. 
If PS _TO_HS.ALLOCATE = YES then 
Set MU.RH.BBI to BB to indicate that this is a BB chain. 
MU.PS_TO_HS.TYPE is not FLUSH then 
Set the RH indicators as described in Figure 6.1-7 on page 6.1-13 based on the value 
of MU.PS_TO_HS.TYPE. 
Set LOCAL.BETC to YES to indicate between-chain state. 
this MU indicates (BC, EC) and there is no data in the RU then 
Convert the RU to an LUSTAT request (set RH bits to indicate FMH and DFC}. 
Set RU to LUSTAT_ RQ RU (see SNA Formats). 


Call DFC_SEND_FSMS(MU) (page 6.1-27). 
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SEND_RSP_IF_REQUIRED 


FUNCTION: Send a response to the passed MU if required. 


INPUT : MU. containing a normal-flow requests information about the last received 
request; indication that a response is owed; the type (positive or negative) 


response to a BB request or RTR request or negative response to the next 
chain; when a negative response is owed, the sense data (included in the 
response). 


OUTPUT: Response sent if required, indication that a response is owed 


Referenced procedures, FSMs, and data structures: 


SEND_RSP_MU page 6.1-45 
FSM_CHAIN_RCV_FMP19 page 6.1-51 
MU page A-29 
LOCAL page 6.0-7 


Select in order, based on the following conditions: 
When a response is owed to a BB request _, 
If a positive response is owed then (it can be said an [LUSTAT,BB]) ‘ ; 
Call SEND_RSP_MU(MU, NORMAL, POS, X'00000000') (page 6.1-45). ag 
Else (-RSP owed to [BB,FMD|LUSTAT]) 
Call SEND_RSP_MU(MU, NORMAL, NEG, LOCAL.BB_RSP_SENSE) (page 6.1-45). 


Reset LOCAL.BB_RSP_STATE to indicate that a response is no longer owed 
-to the BB request. 


When a response is owed to an RTR request 
If a positive response is owed then 
Call SEND_RSP_MU(MU, NORMAL, POS, X'00000000') (page 6.1-45). 
Else (-RSP owed to RTR) 
Call SEND_RSP_MU(MU, NORMAL, NEG, LOCAL.RTR_RSP_SENSE) (page 6.1-45). 


(~ 
Reset LOCAL.RTR_RSP_STATE to indicate that a response is no longer owed Rete a 
to the RTR request. 


When a negative response is owed to the next RU received 
If MU.BCI = BC and (MU.RU_CTGY = FMD or [RU_CTGY 
= DFC and a LUSTAT request]) and the MU.BBI * BB then 
Call SEND_RSP_MU(MU, NORMAL, NEG, X'08460000') (page 6.1-45). 
Reset LOCAL.SEND_ERROR_RSP_STATE to indicate that a negative response is no 
longer owed to the next RU. 


When the state of FSM_CHAIN_RCV_FMP19 = PEND_RSP (a response is owed) and 


the last chain received was CEB,RQD1 . -_ 
Call SEND_RSP_MU(MU, NORMAL, POS, X'00000000') (page 6.1-45). 
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SEND_RSP_MU 


FUNCTION: Create and send a response. The response is based on the request MU (if 
passed by the caller) or on information about the last chain received (if a 
null MU is passed). 


Request MU (if any), flow type (expedited or normal), response type (positive 
or negative), sense data. (Information about the last chain received is used, 
(LOCAL.CT_RCV), when the input request MU has a null value. ) 


OUTPUT: A RSP_MU is built and sent to TC. 


NOTE : When PS sends an MU that indicates a -RSP is to be sent, the RU must be at 
least 4 bytes (for the sense data). 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_FSMS page 6.1-27 
INITIALIZE _TH_RH page 6.1-38 
FSM_CHAIN_RCV_FMP19 page 6.1-51 
RSP_MU, see MU page A-29 
LOCAL page 6.0-7 
MU page A-29 


If no MU is passed by the caller then 
Call buffer manager (GET_BUFFER, permanent buffer pool ID» no wait) to get 
a buffer for building a response MU (RSP_MU). (Appendix B) 
Create a response MU and Call INITIALIZE TH_RH (page 6.1-38). 
Else (reuse the buffer to build a response MU) 
Call INITIALIZE_TH_RH(RSP_MU) (page 6.1-38). 
Set RSP_MU.DCF to the length of RSP_MU.RH. 
Set the RH fields of the RSP_MU to (RSP, BC, EC). 
If a negative response need to send then 
Set RSP_MU.SDI to SD, RSP_MU.RTI to NEG. 
Add the length of RU (contains sense data) to RSP_MU.DCF. 
Copy the input sense data to the RSP.MU. 
Else (positive response) 
Set RTI to POS (indicate a positive response to be sent). 


If input flow type indicates normal-flow then 
If input request MU has a null value (no request MU passed by the caller) then 
Copy the RU_CTGY, DR1I, DR2I, QRI from the correlation table (CT). 
If the RH.RU_CTGY = DFC then 
Add the length of request code to RSP_MU.DCF. 
Set the last byte of the RSP_MU.RU to the RQ CODE from correlation table. 
Record the RQ_CODE from correlation table in LOCAL.COMMON.RQ_CODE. 
Else (a request MU was passed as input) 
Copy the RH.RU_CTGY, DR1II, DR2I, QRI from the input request MU. 
Set LOCAL.COMMON.RQ CODE to the request CODE value from input request MU. 
If the RU category = DFC then 
Add the length of request code to RSP_MU.DCF. 
Set the last byte of the RSP_MU.RU to the RQ_CODE from correlation table. 
Else (expedited, the only expedited-flow response is for SIGNAL) 
Set EFI to expedited, RH.RU_CTGY to DFC, DR1, -DR2, and request code to SIGNAL 
in the RSP_MU. 
Add the length of request code to RSP_MU.DCF. 
Set the last byte of the RSP_MU.RU to the RQ_CODE from correlation table. 
If the RH.RU_CTGY = DFC then 
Set FI to FMH. 
Save the current value of DIRECTION. 
Set the DIRECTION to SEND. 
If executing FSM_CHAIN_RCV_FMP19( response MU) (page 6.1-51) 
would not cause a state-check (>) condition then 
Call DFC_SEND_FSMS(RSP_MU) (page 6.1-27) to send the response. 
Else 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous MU (Appendix B). 
Reset DIRECTION indicator to the saved DIRECTION value. 
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SEND_RSP_TO_RM_OR_PS 


SEND_RSP_TO_RM_OR_PS 


FUNCTION: This procedure builds and sends records to RM or PS based on the received 


response MU. 


INPUT: MU containing a response; indicator that session is first speaker; information 


about the last sent request 


OUTPUT: The appropriate "response" record is sent to RM or 
LOCAL .CURRENT_BRACKET_SQN is’ set to the sequence number of the last sent BB 
request. The ID of the PS connected to this HS may be saved. 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_TO_PS page 6.1-30 
SEND_BID_POS_RSP page 6.1-42 
FSM_BSM_FMP19 page 6.1-50 
CONFIRMED page A-10 
RECEIVE_ERROR page A-10 
BID_RSP page A-11 
RTR_RSP page A-13 
RSP_TO_REQUEST_TO_SEND page A-11l 
MU page A-29 
LOCAL | page 6.0-7 


If the input MU contains an RTR response then 

Create an RTR_RSP record with HS_ID set to LOCAL.HS_ID and send it to RM. 
Else . 
If the input MU contains a SIG response then 

Call DFC_SEND_TO_PS(MU pointer, RSP_TO_REQUEST_TO_SEND) (page 6.1-30). 
Else 

If the response is positive (RTI = POS) then 

If last chain sent was a BB chain and the state of FSM_BSM_FMP19 
(page 6.1-50) is BETB then 
Call SEND_BID_POS_RSP(MU) (page 6.1-42). 


If the form-of-response-requested of the last chain sent was RQD2 or RQD3 then 


Call DFC_SEND_TO_PS(MU pointer, CONFIRMED) (page 6.1-30). 


Else (response is negative) 
If the response sense data is X‘'084¢60000° then 
Call DFC_SEND_TO_PS(MU pointer, RECEIVE_ERROR) (page 6.1-30). 


Else (bracket reject, 1.e., X'08130000', X'08140000', or X'088B0000' ) 
Create a BID_RSP record (indicates negative response and contains the 


sense data from the response) with HS_ID set to LOCAL.HS_ID and send it to RM. 


Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the received MU (Appendix B). 
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a. 


SIGNAL_STATUS 
SIGNAL_STATUS 


FUNCTION: Determine if a SIGNAL is for a past, current, or future bracket. The 
in-bracket (INB) state exists when this procedure is called. 


INPUT : LOCAL .SIG_SNF> LOCAL .CURRENT_BRACKET_SQN, LOCAL .PHS_BB_REGISTER,> 
LOCAL .SHS_BB_REGISTER 


OUTPUT: Either CURRENT, FUTURE, or STRAY return code is set 


Referenced procedures, FSMs» and data structures: 
LOCAL page 6.0-7 
If the sequence number of the last SIGNAL received * LOCAL.CURRENT_BRACKET_SQN then 
Select based on the high-order bit of the SIGNAL SNF (indicates 
whether the primary or secondary half-session started the bracket): 
When PRI | 


Use LOCAL.PHS_BB_REGISTER.NUMBER for the following calculation. 


When SEC 
Use LOCAL.SHS_BB_REGISTER.NUMBER for the following calculation. 


Calculate (SIG_SNF - (PHS|SHS ]_BB_REGISTER.NUMBER ) modulo 215. 
If result is < 0 then 
Set the result to the result plus 2**15 (full_wrap) to determine the 
wrap condition. 
Select based on result of above calculation: 
When result = 0 
Return STRAY signal. 
When result < 2**14 (half_wrap) 
Return FUTURE signal. 
When result > 2%**14 (half_wrap) 
Return STRAY signal. 


Else (sequence number of the last SIGNAL received = LOCAL.CURRENT_BRACKET_SQN) 
Return CURRENT signal. 
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STRAY_RSP 


STRAY_RSP 


FUNCTION: Determines if a response is stray. (A stray response is one that was sent in 
a bracket (conversation) but received ina different (later) bracket.) Logs 


responses. 


INPUT: MU containing a response, information about the last 


LOCAL .CURRENT_BRACKET_SQN, LOCAL .COMMON.RQ_CODE 


request sent, 


OUTPUT: TRUE if stray response; otherwise, FALSE. If stray response represents a 
response correlation error, LOCAL.SENSE_CODE is set and a stray-response mes- 
sage 1s logged. 


An outstanding request is a request that has not been responded or 


Referenced procedures, FSMs, and data structures: 
FSM_BSM_FMP19 
LOCAL 
MU 


If the response is RTR;, there is an outstanding request chain, and the response 


sequence number of the outstanding (awaiting a response) request then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 
Indicate that the response is stray. 


If the response is SIGNAL and its SNF # LOCAL.CURRENT_BRACKET_SQN then 
Indicate that the response is stray. 


If the response is LUSTAT or the RU category is FMD then 
If there is an outstanding request chain then 
If the outstanding chain carried BB and the BB SNF does not match 
that in the response then 
Indicate that the response is stray. 
Else 
If the response SNF * LOCAL.CURRENT_BRACKET_SQN or the state of 
FSM_BSM_FMP19 (page 6.1-50) is BETB then 
Indicate that the response is stray. 
Else (no outstanding request chain) 
Indicate that the response is stray. 


If the response is stray then 
If the response is positive (RTI = POS) and it is not a SIGNAL 
(no positive response other than SIGNAL can be stray) then 
Set LOCAL.SENSE_CODE to X‘200E0000' (response correlation error). 
Else 
Optionally log the stray response to the system log. 


Return with a value of TRUE (stray response). 


Else 
Return with a value of FALSE (not a stray response). 


6.1-48 SNA LU 6.2 Reference: Peer Protocols 


replied to. 


6.1-50 
6.0-7 
A-2 


SNF # the 


TRANSLATE 
TRANSLATE 


FUNCTION: Translate FMD requests, if necessary, to and from the alternate code (e.g., 
ASCII). When receiving, translation is from the alternate code to EBCDIC. 
When sending, translation is from EBCDIC to the alternate code. 


INPUT: MU untranslated, LOCAL.DIRECTION 


OUTPUT: MU, translated if necessary and, if data is to be sent, MU.RH.CSI set to CODE1 


Referenced procedures, FSMs» and data structures: 
MU page A-29 
LOCAL page 6.0-7 


If MU is an FMD request containing RU data other than sense data then 
Select based on LOCAL.DIRECTION: 
When SEND 
If data should be sent as the alternate code (The way the decision 
is made is not architecturally defined) then 
Translate the MU RU data from EBCDIC: to the alternate code. 
Translation details are not formally defined. 
Set MU.CSI to CODE1. 


When RECEIVE 
If MU.CSI = CODE1 then (RU is encoded as the alternate code) 
Translate the MU RU data from the aternate code to EBCDIC. 
Translation details are not formally defined. 
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FINITE-STATE MACHINES 


These are the FSM input definitions used for 
all the FSMs in this chapter: 


¢* R or S: MU that is being processed is 
being received or sent, respectively. 

e RQ, RSP, BC, EC, CD, CEB, FMD, QR: Refer 

to the RH of the MU. 


Refer to val- 
CHAIN_INDICATOR 
In that 


® BEGIN_CHAIN or END_CHAIN: 
ues of CHAIN_INDICATOR. 
does not have to be specified. 


case, it is neither BEGIN_CHAIN nor 
END_CHAIN. 
e RQD: RH set to RQD1, RQDZ, or RQD3. 


e RQE: RH set to RQE1, RQE2> or RQE3. 


e REPLY: A call to OK_TO_REPLY(MU) (page 
6.1-39) returns TRUE. 


FSM_BSM_FMP19 


BIS: MU contains a BIS RU. 
RTR: MU cotains an RTR RU. 
FMH5: MU contains an FMHS. 
FMH12: MU contains an FMH12. 


LUSTAT: 
response. 


MU contains an LUSTAT request or 


NOT_BID_REPLY: RH set to (BC, -BB) and 
either the last sent chain did not carry 
BB or a call to OK_TO_REPLY (page 6.1-39) 
returns a value of FALSE. 


CEB_UNCOND: RH set to (CEB, RQ*1). 


FUNCTION: Enforce the bracket protocol. State transitions are forced via the input |-~. 
Signals INB (go in brackets) and BETB (go between bracket}. The inputs R> 
RQ,... are used for error checking’ only. INB state means DFC (the é 
half-session) is connected to a PS; BETB state means DFC is not connected to a 
PS. 
INPUT: MU or a signal that the FSM should be set to the specified state 
OUTPUT: If an error is discovered, LOCAL.SENSE_CODE is set. 
NOTE : The state names mean the following: 
e §6©6BETB: between brackets 
| ae 
e INB: in bracket 
ee 


Referenced procedures, FSMs, and data structures: 
MU 
LOCAL 


INPUTS 


OUTPUT | FUNCTION 
CODE 
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Set LOCAL.SENSE_CODE to X'20030000' (bracket error). a 


* 


FSM_CHAIN_RCV_FMP19 


FSM_CHAIN_RCV_FMP19 


FUNCTION: 


INPUT : 


OUTPUT : 


Enforce the chaining protocol for received chains. A chain is “complete" when 
the end-of-chain (EC) request has been received and any required associated 
response or reply has been sent. A reply is a request sent after receiving an 
(RQE,CD) chain that has not been negatively responded to. A_ reply implies a 
positive response to the (RQE,CD) chain. 


MU, CHAIN_INDICATOR (possible values are  BEGIN_CHAIN, END_CHAIN'- and 
NOT_SPECIFIED), information about the last received request 


If the bracket was ended by the request, the HS will be disconnected from PS; 
information recorded about the last received request may be erased; 
LOCAL.SENSE_CODE may be set. 

The state names mean the following: 

e 8636BETC: between chains 


e INC: in the middle of a chain 


NEG RSP SENT: in the middle of a chain and a_ negative response has been 
sent 


PEND RSP: has received (EC,RQD) and is waiting for the response’ to be 
sent 


PEND SEND REPLY: has received (EC,RQE,CD) and is waiting for the reply or 
negative response to be sent 


Referenced procedures, FSMs, and data structures: 


OK_TO_REPLY page 6.1-39 
FSM_BSM_FMP19 page 6.1-50 
MU page A-29 
FREE_SESSION page A-12 
LOCAL page 6.0-7 
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FSM_CHAIN_RCV_FMP19 


6.1-52 


STATE NAMES---->| BETC INC 
INPUTS STATE NUMBERS--> 02 
R»RQ,BEGIN_CHAIN / 
R»RQ,END_CHAIN,RQD vA 
R»RQ,END_CHAIN,RQE »CEB 1(A) 


R»RQ,END_CHAIN,RQE ,CD 
R»RQ,END_CHAIN,BIS 


S,-RSP,( FMD|ILUSTAT ) 
S,+RSP ,( FMD|LUSTAT ) 
S,+RSP,RTR 


S»,RQ,REPLY 


R»RQ,BC >(R1) >(R1) 


R»RQ,-BC >(R1) 


SIGNAL (RESET ) 


epep | 


pay ; 


OUTPUT 
CODE 


FUNCTION 


If the last chain received did not carry BB or 
(it carried BB and it was accepted, i.e.» there was no negative response to the 
BB chain with sense data X'08130000', X'08140000', or X'088B0000') then 
If the bracket has ended (the last received chain carried CEB and either [1] 
the form-of-response-requested was RQE or RQD1, or [21] no negative response 
was sent to the chain) then 


Create and send a FREE_SESSION record to RM. 
Call buffer manager (ADJUST_BUF_POOL, dynamic buffer pool ID; 
REPLENISHED pool size) to keep the same pool size 
(see Appendix B). 
Call FSM_BSM_FMP19 with a BETB signal (page 6.1-50). 
Reset LOCAL.BRACKET_ID to a null value. 
Reset correlation table CT_RCV entry to NO. : 


: 
a 
Sed & 
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FSM_CHAIN_SEND_FMP19 


FSM_CHAIN_SEND_FMP19 


FUNCTION: Enforce the chaining protocol for sending chains. A chain is “complete" when 
the end-of-chain (EC) request has been sent and any required associated 
response or reply has been received. A reply is a request received after 
sending an (RQE,CD) chain that has not received a negative response. A reply 
implies a positive response to the (RQE,CD) chain. 


MU; | CHAIN_INDICATOR (possible values are  BEGIN_CHAIN, END_CHAIN- and 
NOT_SPECIFIED), information about the last received request. 


If the bracket was ended by the request, the HS will be disconnected from PS; 
information recorded about the last received request may be erased; 
LOCAL.SENSE_CODE may be set. 

The state names mean the following: 


e BETC: between chains 


INC: in the middle of a chain 


NEG RSP RCVD: in the middle of a chain and a negative response has been 
received 


PEND RSP: has’ sent (EC,RQD) and is waiting for the response to be 
received 


PEND RCV REPLY: has sent (EC,RQE,CD) and is waiting for the reply or neg- 
ative response to be received 


Referenced procedures, FSMs, and data structures: 


OK_TO_REPLY page 6.1-39 
FSM_BSM_FMP19 page 6.1-50 
FREE_SESSION page A-12 
MU page A-29 
LOCAL page 6.0-7 


STATE NAMES--~-~-> 


INPUTS STATE NUMBERS--> 


S »RQ,BEGIN_CHAIN 
S,RQ,END_CHAIN,RQD 
S,RQ,END_CHAIN,RQE ,CEB 
S,RQ,END_CHAIN,RQE CD 
S ,RQ,END_CHAIN,BIS 


R»-RSP,( FMD|LUSTAT ) 
R»+RSP,( FMD|LUSTAT ) 
R»+RSP,RTR 
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FSM_CHAIN_SEND_FMP19 


OUTPUT | FUNCTION 
- CODE 


If the last chain sent did not carry BB or 
(it carried BB and it was accepted, i.e., there was no negative response to the 
BB chain with sense data X'08130000', X'08140000', or X'088B0000') then 
If the bracket has ended (the last sent chain carried CEB and either [1] 
the form-of-response-requested was RQE or RQD1, or [2] no negative response 


was received for the chain) then 
Create and send a FREE_SESSION record to RM. 
Call FSM_BSM_FMP19 with a BETB signal (page 6.1-50). 
Set LOCAL.BRACKET_ID to NULL. 
Set correlation entry to indicate no request chain outstanding. 


Set correlation entry to indicate no request chain outstanding. 
Set LOCAL.SENSE_CODE to X'200F0000° (response protocol error). 
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C) 


FSM_QRI_CHAIN_RCV_FMP19 


FSM_QRI_CHAIN_RCV_FMP19 


Enforce the setting of the QRI indicator in the RH. This indicator is set the 
same for all MUs in a chain; 1.e., all MUs ina chain have QRI=QR_ or have 


QRI=-QR. 


MU and information about the last received request 


If a QRI state error is detected, LOCAL.SENSE_CODE is set. 
1) The state names mean the following: 

@ RESET: no chain is currently being received. 

e INC QR: the chain that is being received is a QR chain. 


e = =6INC NOT QR: the chain that is being received is not a QR chain. 


2) The implementation of this FSM is optional because it 1s used only to 


detect receive error conditions. 


Referenced procedures, FSMs, and data structures: 


INPUTS 


R»RQ, QR, EC 
R»RQ, QR»-~EC 


R»RQ,-QR, EC 
R »RQ,-QR,-~EC 


SIGNALCRESET ) 
OUTPUT FUNCTION 
CODE 


STATE NAMES----> 


STATE NUMBERS~--> 


LOCAL.SENSE_CODE to X'200B0000' (QRI state error). 
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FSM_RCV_PURGE_FMP19 


6.1-56 


FSM_RCV_PURGE_FMP19 


FUNCTION: 


INPUT: 


OUTPUT : 


Referenced procedures, FSMs, and data structures: 


INPUTS 


R> 
SIGNAL ( PURGE ) 


SIGNALC RESET ) 


EC 


MU 


Maintain a purging state for received BB chains that have been negatively 
responded to indicating a bracket error (0813, 0814, 0888). It is called with 
a PURGE signal when the negative response is sent and reset when the 
end-of-chain (EC) RU is received. When in the purging state, no records are 


generated for PS or RM as a result of receiving a request RU in the BB chain 
(i.e., the remainder of the BB chain is purged). 


MU and information about the last received request 


None 


STATE NAMES----> 
STATE NUMBERS--> 
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CHAPTER 6.2. TRANSMISSION CONTROL 


INTRODUCTION 


The basic function of the transmission con- 
trol (TC) component is to control the flow of 
data between the half-session and path con- 
trol. Transmission control participates in 
two activities: 


e Initialization: 


- Variable initialization 
—- Cryptography initialization 


e Normal operation: 


—- Sending data from data flow control 
(DFC} to path control (PC) 

- Receiving data from PC and sending it 
to DFC 


TC.INITIALIZE (page 6.2-13), the procedure 
for session initialization, is invoked after 


the LU session manager (SM) processes a 
+RSP(BIND ). TC .INITIALIZE provides 
session-specific support for starting data 
flows in the session. When session-level 
cryptography 1s used, TC.INITIALIZE checks 
that the enciphering and deciphering func- 
tions are operative before any user data is 
permitted to flow. 


The SEND_MU and TC.RCV procedures manage the 
expedited and normal flows, and control 
sequence-number updating, receive-checking, 
session-level pacing,» and data enciphering 
and deciphering. 


The relationship of transmission control to 
the other elements of the half-session, after 
initialization, is shown in Figure 6.2-1 on 
page 6.2-2. 
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Resource Manager (RM) 
(See Chapter 3) 


-_ 


A 
Session Presentation Services (PS) 
Manager (SM) (See Chapter 5.0) 
A A 
2 a 


Data Flow Control 
(See Note 2) 


DFC_INITIALIZE 
DFC_SEND_FSMS) DFC_RCV 
A 


+ 
Hal f—Session 
Router Transmission Control 
(See Note 1) 
a 
\ y 
A ae 
Half—Session ‘< 
(Receive Data) (Send Data) GET_BUFFER \- 
V | FREE_BUFFER 
Path Control (PC) ADJUST_BUF_POOL 
V 
Buffer Manager (BM) 
Notes: 


(See Note 3 ) 
1. See “Chapter 6.0. Half—Session" for details. 
2. See "Chapter 6.1. Data Flow Control" for details. 
3. HS Router and DFC also interact with the BM, but this 1s not shown 
in the figure. See HS, DFC chapters for details. : 
Figure 6.2-1. Structure of TC and Flow of Data within the Half-Session 
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INITIALIZATION PHASE 


TC.INITIALIZE (page 6.2-13) is called by 


HS_INITIALIZATION ("Chapter 6.0. 
Half-Session") during initialization when a 
half-session 1s being activated. 


TC.INITIALIZE sets up session-level pacing 
and cryptography verification variables. 


CRYPTOGRAPHY VERIFICATION (CRV) 


For sessions that support cryptography, the 
initialization procedure calls 
TC .EXCHANGE_CRV (page 6.2-15) to perform the 
message-unit exchanges necessary to enable 
data enciphering and deciphering. 


Flow: From primary LU to secondary LU (Expedited) 


When session-level cryptography is specified 
in the BIND, CRV is sent by the primary LU TC 
to the secondary LU TC to enable sending and 
receiving of enciphered FMD requests by both 
half-sessions. CRV is a valid request only 
when session-level cryptography is selected 
in BIND. CRV carries an 8-byte field (see 
SNA Formats) that contains a transform of the 
deciphered test value (enciphered under the 
session cryptography key). The test value is 
received by the primary LU in the +RSP(BIND); 
the transform in CRV is the test value with 
each bit of its first four bytes inverted 
(1.e., a 1 becomes a O and a O becomes a 1). 
(The test value is also used as the session 
seed, or initial chaining value, when enci- 
phering and deciphering FMD RUs while the 
session is active.) The secondary TC element 
obtains the returned test value by decipher- 
ing the aforementioned 8-byte field in CRV 


and inverting the first four bytes; it then 
compares it with the test value sent (enci- 
phered) in +#RSP(BIND). If the values donot 
match the session cryptography key and the 
session seed, the session is deactivated. 


Valid cryptography options are defined under 
the BIND format in SNA Formats, which also 
describes the RH bits used for cryptography. 


Where session cryptography is used, session 
key distribution is managed by the CP of the 
primary LU; session Keys are conveyed (enci- 
phered under LU master cryptography Keys) to 
the PLU in a CINIT RU and then to the second- 
ary LU in a BIND request (see SNA Formats and 
Figure 6.2-2 on page 6.2-4). The flows 
involved in distributing the session seed to 
the LU are _ shown in Figure 6.2-2 on page 
6.2-4. 
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cp PRIMARY LU SECONDARY LU 
CINIT (MKp [SK] 0, MKs [SK] 0) [1] 
ie (MKs [SK] 0) [2] 
RSP(BIND, SK [SS] 0) : [3] 
tay {transformed SS] 0) [4] 
RSP(CRV) ° [5] 
< 


> 


FMD request(SK [RU data] SS} [6] 


FMD request(SK [RU data] SS) [6] 
FD A A ES 


LEGEND: 
MKp master cryptography key for primary LU (obtained from 
installation and implementation dependent system definition). 
MKs master cryptography Key for secondary LU (obtained from 
installation and implementation dependent system definition). 
SK session cryptography Key 
Ss session seed 


NOTE: Enciphered data is represented in the diagram as follows: 


cryptography Key [ data ] initial chaining value 


For example, to show an RU that was enciphered using the session Key 


as the cryptography key and 0 as the initial chaining value, 
the following string is used: 


SK [RU datal 0. 


Figure 6.2-2. Distributing the Session Cryptography Key and Session Seed to the LU 


The comments below correspond to the numbers 
in Figure 6.2-2. 


1. In the CINIT RU, the session cryptography 
key is distributed to the primary LU in 
two enciphered formats: it is enciphered 
using the master cryptography Key of the 
primary LU and in another field it is 
enciphered using the master cryptography 
key of the secondary LU. The initial 
chaining value is 0 for both cases. 


2. In the BIND RU, the primary LU sends the 4. 
session cryptography Key to the secondary 
LU as it was received in the CINIT RU: 
enciphered using the master cryptography 
key of the secondary LU as_ the 
cryptography Key and 0 as the initial 
chaining value. 


3. The secondary LU deciphers the session 
cryptography key using its master 
cryptography key as the cryptography key 
and 0 as the initial chaining value. The 
secondary LU then generates a 
pseudo-random value, retains it for use 
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as the session seed, and enciphers it 
using the session cryptography key as the 
cryptography Key and 0 as the initial 
chaining value. This enciphered value is 
returned on the response to BIND. The 
value serves two purposes: it is used as 


Pree 


Ns oi 


a test value (i.e., when returned in CRV. 


discussed below), and is_ subsequently 
used as the session seed, or initial 
chaining value, in enciphering and deci- 
phering FMD requests within the session. 


The primary LU deciphers the test value 
received in the RSP(BIND) using the ses- 
sion cryptography Key as the deciphering 
key and 0 as the initial chaining value. 
The resulting value is retained for use 
as the session seed and then transformed 
by exclusive-ORing it with 
X'FFFFFFFFOOOOOOOO'. This inverts’ the 
bit settings in the first four bytes. 
The transformed value is then enciphered 
using the session cryptography Key as the 
Key and 0 as the initial chaining value. 
This transformed, enciphered value is 
sent on the CRV request. 


( - 
ee 


a 


| 
Expedi ted—f low 


RQ&RSP 


The secondary LU deciphers the enci- 
phered, transformed test value using the 
session cryptography Key as. the Key and 0 
as the initial chaining value. The 
result is then  exclusive-ORed with 
X'FFFFFFFFOOOO0000' to recreate the ori- 
ginal pseudo-random value sent by the 
secondary LU in RSP(BIND). The recreated 
value is compared with the actual value 
that was created by the secondary LU. If 
the recreated value matches the original 
value, a positive response is sent to 
CRV. The test value can then be used as 
the session seed. 


From then on, all FMD requests are enci- 
phered using the session cryptography Key 
as the Key and the session seed as the 
initial chaining value. 


Data Flow Control (DFC) 


Normal—flow 
RQ&RSP 


V 
— | q PAC 
—— (send pacing queue) 


Path Control 


Figure 6.2-3. SEND MU and TC.RCV Request/Response Flow 


TC.RCV 


Transmission Control 


Cryptography verification is the only session 
control (SC) request handled by TC. SC 
requests for session activation and deacti- 
vation (for example, BIND and UNBIND) are 
routed from PC to SM (see "Chapter 4. LU Ses- 
sion Manager") without passing through TC. 
Session control requests and responses have 
the header bit-settings described below. 


All session control requests are issued by TC 
or by SM. The following fields of the TH and 
RH are set for session control RUs. 


TH: All session control requests and 
responses are sent expedited (the EFI bit 
is on in the TH). 


RH: The RH settings for session control 
requests are defined in TC.BUILD_CRV on 
page 6.2-17 . 


Half—Session 
Router 
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NORMAL OPERATION 


6.2-6 


flushing a 


The request and response flow with SEND_MU 
and TC.RCV protocol machines are shown in 
Figure 6.2-3. Detailed definitions for 
SEND_MU and TC.RCV, the major TC procedures, 
are shown on page 6.2-20 and page 6.2-23 , 
respectively. 


The protocols supported by TC include: 
e Checking of sequence numbers on received 


normal-flow requests (Sequence numbers 
are assigned to normal-flow requests by 


DFC, see "Chapter 6.1. Data Flow Con- 
trol") 
e Proper separation of the normal flows 


from the expedited flows with respect to 
sequencing and pacing 


e Sending of normal-flow requests using 
pacing, which involves a queue (LO- 
CAL.Q_ PAC) for temporarily holding outgo- 
ing requests 


¢ Proper routing of requests and responses 
to PC and DFC 


e Enciphering and deciphering control for 
all LU-LU FMD request RUs on sessions 


using session-level mandatory 
cryptography (see TC.DECIPHER_RU [page 
6.2-32]) 


TC PROCEDURES INVOKED FROM OTHER COMPONENTS 
OF THE HALF-SESSION 


Procedure TC.RCV (page 6.2-23) is invoked by 
the half-session router (see "Chapter 6.0. 
Half-Session" for details). 


When the half-session router receives a mes- 
sage unit (MU) from path control, it calls 
TC.RCV to initiate TC processing of the mes- 
sage unit. 


SEND_MU (page 6.2-20) is called by DFC when 
DFC has a full buffer to send or when DFC is 
partially filled buffer. The 
buffer is considered full when 1t reaches the 
maximum RU size as specified in BIND. 


SEQUENCE NUMBERING OF REQUESTS AND RESPONSES 


For TS profile 7 (see SNA Formats), each 
request that is sent on the normal flow is 
assigned a sequence number. The sequence 
number is initialized to 0 when a 
half-session is activated (BIND is sent or 
received); it is incremented by 1 before 
sending each request. Thus, the sequence 
number for the first request is 1. After 
reaching 65,535, the sequence number wraps to 
0. (A sequence number of 0 is sent in the 
wrap situation only.) Sequence numbers are 
assigned in the sending half-session by DFC 
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and are checked in the receiving half-session 
by TC. 


For the expedited flow, an identifier is 
assigned to each request sent. The identifi- 
er is not necessarily managed as a sequence 
number, but 1s used to uniquely identify each 
outstanding expedited-flow request sent. The 
expedited-flow DFC request SIGNAL is assigned 
an identifier by DFC; the expedited-flow SC 
request CRV is assigned an identifier by TC; 
expedited-flow session-activation (BIND) and 
session-deactivation (UNBIND) requests are 
assigned identifiers by SM (see "Chapter 4. 
LU Session Manager"). 


The sequence number or the identifier, as 
appropriate, is given to path control with 
the associated BIU, to be carried in the TH. 


The sequence number or identifier generated 
by the sending component is retained for use 
in correlating responses to requests (a 
response carries the sequence number -or iden- 
tifier of the corresponding request). 


See “Sequence Numbering of Requests and 
Responses" in “Chapter 6.1. Data Flow Con- 
trol". for further information on sequence 
numbering. 


SESSIONS WITH CRYPTOGRAPHY 


If session-level mandatory cryptography is 
selected when the session is activated, TC 
enciphers all FMD request RUs being sent and 
deciphers all those being received. The 
process of enciphering involves the following 
actions: 


e The RU is padded, when necessary, to an 
integral multiple of eight bytes. The 
padding bytes are added at the end and 
contain unpredictable values, except for 
the last pad byte, which contains an 
unsigned 8-bit binary count of the pad 
bytes. If only one byte of pad is 
required, that byte is the pad byte and 
it contains a 1. If padding is per- 
formed, the padded data indicator (PDI) 
in the RH is set to PD. (The LU control 
operator checks that the system defined 
maximum RU size is a multiple of 8 during 
initialization time. See "Chapter 5.4. 
Presentation Services--Control-Operator 
Verbs" for details. ) 


¢ Prior to enciphering, the first eight 
bytes of an RU are exclusive-ORed with 
the session seed (1.e., the initial 
chaining value); the result is then enci- 
phered. Each subsequent 8-byte block 
within the same RU is exclusive-ORed with 


‘ 


oon 


i 


the output of the previously enciphered/ ~ 


block. This technique is referred to as| 


“block chaining with cipher text feed- ~~’ 


back." When an enciphered RU is sent, 


a 


the Enciphered Data indicator (EDI) in 
the RH is set to ED. 


® Enciphering employs an 8-byte block chain 
algorithm and an 8-byte key, the session 
cryptography Key» and is in accordance 
with the Data Encryption Standard (DES) 
algorithm described in Federal Informa- 
tion Processing Standards Publication 46, 


OR ENA END | ENE ARATE | REARS | GAMES 


dated January 15, 1977. 


The deciphering process is simply the inverse 
of enciphering. 


REQUEST AND RESPONSE CONTROL MODES 


TC enforces the immediate request mode during 
cryptography verification (CRV) exchange as 
part of TC initialization. The last thing 
that the primary TC does during initializa- 


tion is to send a CRV request and receive the 
CRV response. The last thing that the sec- 


ondary TC does during initialization is to 


receive the CRV request and send the CRV 
response. TC accepts no other records from 
HS components, and nothing from path control 
(PC) except CRV, during this time. (See "Re- 
quest/Response Mode Protocols" in Chapter 6.1 
for details. } 


TC is not involved in enforcing immediate 
request mode at any other time, and it is not 
involved in enforcing immediate response mode 
at any time. 


BUFFER MANAGEMENT 


On sending a normal-flow request, path con- 
trol (or data link control, 1 segment gener- 
ation is not supported) frees the limited 
buffer which the normal-flow request was in 
and sends the request to the partner LU. On 
receiving a normal-flow request, data link 
control stores the request ina link buffer. 
The data remains in the link buffer until TC 
receives it. TC frees the link buffer after 
moving the data to a fixed/varying dynamic 
buffer. (Dynamic buffers are used to receive 
normal-flow requests. ) 


TC calls the buffer manager (BM) to obtain 
buffer management services and specifies the 
following signals: (see Appendix B for more 
details) 


¢ TC specifies FREE_BUFFER in the Call to 
the buffer manager to release a link 
buffer in which session data (1.e. MU, 
IPM) was received. 


e TC specifies ADJUST_BUF_POOL in the Call 
to allow the BM to decrease the the num- 
ber of limited buffers in a limited buff- 
er pool when an unsolicited IPM (1.e. 
next-window size = 0) is received. 


e¢ TC specifies ADJUST_BUF_POOL in the Call 
to allow the BM to increase the number of 
limited buffers in a limited buffer pool 


when a solicited IPM (i.e. next-window 
size > 0) 1s received. 


e TC specifies GET_BUFFER in the Call to 
get a permanent buffer to send IPM 
acknowledgment to its partner. 


e TC specifies GET BUFFER in the Call to 
get a fixed/varying dynamic buffer to 
store a received normal-flow request. 


SESSION-LEVEL PACING 


Session-level pacing allows TC to control the 
rate at which it receives requests on the 
normal flow. If pacing is selected when the 
session is activated, all normal-flow 
requests are paced. Send pacing controls the 
outbound flow of data. Receive pacing con- 
trols the inbound flow of data. The SEND MU 
procedure (page 6.2-20) performs send pacing 
requests and has a session partner TC.RCV 
procedure (page 6.2-23) that is doing receive 
pacing requests. Requests and responses on 
the expedited flow are not paced and are 
unaffected by pacing on the normal flow. 
Pacing is generally used when the sending TC 
is capable of sending requests faster than 
the receiving TC can process’7 them. A 
normal-flow response with the QR bit (in RH) 
set is also paced. 


The pacing environment assumes’ that the 
receiving TC is able to accept no more than a 
certain number of requests at a time. This 
number, called the window size, is defined 
initially when the session is being acti- 
vated. 


For fixed pacing, the window size remains 
constant; for adaptive pacing, it varies from 
window to window, as explained later. Pacing 
operates according to the following cycle. 
At the start of a session, the sending TC may 
send a window whose size is 1 for adaptive 
pacing, or whose size is set in BIND or 
RSP(BIND) for fixed pacing (depending = on 
whether nonnegotiable or negotiable BIND, 
respectively, is used). On the first request 
of any window, the sending TC turns on the 
Pacing Request indicator (PI). After the 
receiving TC receives the request that con- 
tains the Pacing Request indication, it can 
signal the sending TC (by using the Pacing 
Response indication) when it 1s ready to 
receive another group of requests. 


The sending TC Keeps a count of the residual 
number of requests that it can send before 
receiving a pacing response. (This value and 
all others related to session-level pacing 
and the maximum RU size are maintained in the 
transmission-control control block [LO- 
CAL.TC.COMMON_CB] which is a substructure of 
the page 6.0-7.) Assume the current window 
size is N. When a pacing response is 
received, the sending TC is informed by the 
BM that additional window is available and 
therefore increases the pacing count by N for 
fixed pacing, or the value N' indicated by 
the pacing response (1.e. solicited IPM) for 
adaptive pacing. This makes the pacing count 
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equal to the new window size (N or N') plus 
the residual pacing count (the remaining 
requests not yet sent from the previous win- 
dow). If the pacing count drops to 0, the 
sender waits until a pacing response is 
received before sending any more requests. 
The value of the pacing count can range from 
0 to 2N-1 (for fixed pacing) or N-1+N‘' (for 
adaptive pacing). 


The pacing response may be returned as fol- 
lows: for fixed pacing, on a normal-flow 
response header or on an ISOLATED PACING 
RESPONSE (IPR); for adaptive pacing» on an 
ISOLATED PACING MESSAGE (IPM), either solic- 
ited or unsolicited. 


1. For fixed pacing, only one IPR is gener- 
ated for each pacing request. the IPR 
may be used at any time when fixed pacing 
is supported; however, it is especially 
useful when no other response to a 
request is available in which to send the 
pacing response or when the available 
response is blocked on the pacing queue. 
IPR can be sent on the normal or expe- 


dited flow. 


2. For adaptive pacing, a solicited or unso- 
licited IPM is returned for the pacing 
request. If it is necessary, an unsolic- 
ited IPM may be used even without receiv- 
ing a pacing request previously. A reset 
acknowledgment IPM is generated as a 
response for each unsolicited IPM. The 
next unsolicited IPM can be used only 
when the reset acknowledgment IPM is 
returned for the current unsolicited IPM. 
If an unsolicited IPM carries a next win- 
dow size (NWS) of 0, the sending TC uses 
a solicited IPM after receiving a IPM 
acknowledgement in order to allow paced 
normal-flow requests to resume flowing. 
An IPM is sent on the expedited-flow. 


The decision on whether there are sufficient 
resources for sending a pacing response is 
imp lementation-dependent. 


Normal-flow responses that have the Queued 
Response indicator (QRI) set to QR are placed 
on the pacing queue (Q_ PAC), but do not cause 
the pacing count to be decremented when they 
are sent. When normal-flow responses indi- 
cate -QR, they can pass_ requests and 
responses marked QR at the queuing point in 
TC. If a request is held up by pacing, all 
responses marked QR and queued behind the 
request are also held up. 


A Pacing Response indication is never added 
to a response held in Q PAC; it is added only 
to a response(i.e., a "piggy backed" pacing 
response) with QRI=QR as it is dequeued from 
Q PAC or to a response with QRI=-QR when it 
is sent. An IPR can be generated and sent 
directly to PC to prevent session deadlock, 
which could occur when both TC pacing queues 
contain a request that cannot flow and that 
blocks the flow of the only available 
responses that might be used to carry the 
Pacing Response indication. 
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Although the no-pacing option exists, only T5 
node LUs support receipt of unpaced data. 


When a T2.1 node LU sends a BIND, it sets the 
staging indicators to specify one-stage in 
both directions, and sets the pacing window 
sizes to values determined by 
installation-dependent considerations. When 
a subarea LU sends an SSCP-mediated BIND, the 
values for the staging indicators and pacing 
windows are contained in the BIND image sent 
to the LU in CINIT; which the PLU may or may 
not place in the BIND RU. For the format and 
meanings of the pacing parameters in BIND, 
see SNA Formats for details. 


An IPR or IPM is sent to return a Pacing 
indication as discussed in the preceding sec- 
tion. For IPR, no RU accompanies the TH and 
RH. The format of the IPR and IPM are 
defined in SNA Formats 


Solicited and unsolicited IPMs flow at net- | 


work priority between T2.1 nodes. Reset 
acknowledgment IPMs flow at the priority of 
the session (between T2.1 nodes or in a sub- 
area network) so that it does not overtake 
any BIUs en route, thereby truly delimiting 
the end of the reset window. (See page 
6.2-22 for priority setting, and see SNA Type 
2.1 Node Reference for details on trans- 
mission priority. ) 


SESSION-LEVEL PACING ALGORITHMS 


A session can be viewed as a succession of 
adjacent pairs of session-level processing 
points (involving half-sessions and boundary 
function components). The connection between 
a pair of these processing points is called a 
session stage. 


While adaptive pacing is the preferred mode, 
the session pacing algorithm is able to sup- 
port fixed-pacing protocols when the other 
partner of a session stage does not support 
adaptive pacing. 


The session-level pacing modes for both send- 
er and receiver are determined during the 
BIND negotiation time for each session stage. 
The sender TC sends data, pacing requests, 
and IPM acknowledgments. The receiver TC 
receives data and pacing requests, generates 
appropriage pacing responses, has its buffer 
manager reserve buffers, and determine the 
next-window size (NWS). 


Session-Level Adaptive Pacing Algorithm 


Session-level adaptive pacing uses the fol- 
lowing flow-control messages: 


e Pacing Requests 
e ISOLATED PACING MESSAGES (IPMs ) 
- Solicited 


- Unsolicited 


(— 
¥s 
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- Reset Acknowledgments 


A pacing request is a normal-flow request 
that has the pacing indicator (PI) in the RH 
set to PAC. A pacing request indicates that 
an RU is the first RU in the last window 
allowed, and requests that a new window be 
allowed. 


A solicited IPM is generated by the receiver 
when the receiver has reserved the buffers 
for a new window in response to a pacing 
request sent by the sender. A solicited IPM 
informs the sender what its new pacing window 
size is that it can send following the cur- 
rent window it is sending. 


An unsolicited IPM is generated by the 
receiver as a result of congestion in the 
node and is used to reset to 0 the residual 
pacing count in the sender and to start a new 
pacing window if the next-window size speci- 
fied in the IPM is not 0. The sender imme- 
diately sends a reset acknowledgment IPM when 
an unsolicited IPM arrives; this delimits the 
end of the window being reset and allows the 
sender of the unsolicited IPM to reallocate 
resources. 


A reset acknowledgment IPM is an immediate 
acknowledgment that an unsolicited IPM has 
reset the residual pacing count. The reset 
acknowledgment IPM also echoes the 
next-window size specified in the unsolicited 
IPM. 


OPERATION OF THE SENDER 


The following algorithm is implemented in all 
nodes that use adaptive pacing. The sender 
mechanism is unaffected by the algorithm used 
to determine the pacing window sizes. 


Whenever the remaining number of the current 
window (hereafter referred to as the residual 
pacing count) is non O and a normal-flow 
request is at the head of the pacing queue, 
it is sent and the residual pacing count is 
decremented by 1. If, at any time, the resi- 
dual pacing count is O and the next-window 
size is non 0, the residual pacing count is 
set to the next-window size, the next-window 
size is reset to 0, and the Pacing indicator 
is set to PAC in the RH of the next request 
sent. Whenever any thing besides a 
normal-flow request is at the head of the 
queue it is sent right away. 


When aie solicited or unsolicited IPM is 
received, the new next-window size is 
obtained from the IPM. 


When it is an unsolicited IPM, a_ reset 
acknowledgment IPM is returned immediately 
and the residual pacing count is reset to O. 
The reset window indicator (RWI) bit in an 
unsolicited IPM is always set to 1 (indicat- 
ing a reset action is needed). 


The Request Larger Window indicator (RLWI} in 
the request RH is used by the pacing request 


sender to indicate to the receiver that it 
would like a larger window size. The RLWI 
has meaning only in pacing requests and is 
reserved in responses. When the sender 
receives a solicited IPM and the residual 
pacing count is 0 (the entire previous pacing 
Window has been sent) and the send pacing 
queue is not empty (more requests are avail- 
able to send), the sender will send the next 
Pacing request with RLWI set to request a 
larger window (set to a value of 1, or RLW). 
Otherwise, the sender sends a pacing request 
with RLWI set to -RLW, indicating a larger 
window size is not needed. 


The pacing request receiver uses the RLWI 
value in calculating the next-window size 
value to be sent in the next solicited IPM. 


The sender is initialized by the session man- 
ager with a next-window size of 1 and a resi- 
dual pacing count of 0 when the session is 
activated. 


OPERATION OF THE RECEIVER 


The receiver has control and responsibility 
for session-level pacing» as necessary to 
manage its buffers. 


An unsolicited IPM with the RWI set to 1 is 
sent whenever the node becomes congested. 
The receiver may not have more than 1 out- 
standing unsolicited IPM. Another IPM (so- 
licited or unsolicited) may not be sent until 
the reset acknowledgment IPM is received. 
When an unsolicited IPM is outstanding, the 
receiver's buffer manager does not reserve 
buffers for the next window as a result of a 
pacing request that was received before the 
reset acknowledgment IPM. (A solicited IPM 
will not be sent for pacing requests that are 
received before the reset acknowledgment 
IPM. ) 


Fixed pacing is implemented as a special case 
of adaptive pacing. The "piggybacked" pacing 
response (1.e. on a regular response--1 with 
(DR1I, DR2I)#00--occurs only for fixed pac- 
ing. 


When the data sender receives an unsolicited 
IPM with a next-window size of 0, it is 
stopped from sending normal-flow requests. 
When the data receiver gets the _ reset 
acknowledgment IPM (in response to the unso- 
licited IPM) the sender's window size (and 
its residual pacing count) has been reset to 
0 and no further normal-flow requests may be 
sent by the sender. In order to allow the 
sending of more normal-flow requests, a 
solicited IPM, which always contains a non 0 
next-window size, is sent by the receiver. 
The sender may resume sending requests when 
this solicited IPM has been received. The 
next-window size value used in this solicited 
IPM is typically small (e.g., 1). 


Window sizes can vary from 1 to 32767 in 


solicited IPMs and 0 to 32767 in unsolicited 
IPMs. 
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Manager" for details of how buffers are man- 
aged to perform session-level pacing. An 
(sender ) 
NWS RPC 
BIND 
> 
+RSP( BIND ) 
1 1 0 < 
RQ,PAC ,RLW 
2 8) 0 ————————eeeeeee > 
IPM (solicited, NWS=2) 
3 2 0 < 
RQ ,PAC »RLW 
4 O 1 —————_______—_> 
IPM (solicited, NWS=3) 
5 
RQ,-PAC 
6 0 0 > 
7 3 0 < 
RQ,PAC,-RLW 
8 0 2 ee > 
IPM (solicited, NWS=2) 
9 2 2 < 
RQ,-PAC 
10 2 1 > 
RQ ,~PAC 
ll 2 0 > 
RQ,PAC »>~RLW 
12 0 1 > 
RQ, ~PAC 
13 0 0 > 
LEGEND 
NWS next-window size 
RPC residual pacing count 
RQ request 
PAC Pacing indicator set to 1 
~PAC Pacing indicator set to 0 
RLW Request Larger Window indicator set to 1 
-RLW Request Larger Window indicator set to 0 


Figure 6.2-4. 
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Figure 6.2-4 and Figure 6.2-5 illustrate 
adaptive session-level pacing, with session 
data traffic flowing from left to right ona 
given session stage. See "Appendix B. Buffer 


The comments below correspond to the numbers 
in Figure 6.2-4 on page 6.2-10. 


1. When a session using adaptive pacing is 
initialized, it starts with a next-window 
size of 1 and a residual pacing count of 
QO. 


2. The first request in a window has the 


Pacing indicator set to PAC. The RLWI is 
set to RLW in this example. 
3. The receiver increases the sender's 


next-window size to 2. The sender's res- 
idual pacing count is at 0 and the pacing 
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Session-Level Pacing with Solicited IPMs 


analogous set of exchanges could occur in the 


opposite direction. 
sion 


See "Chapter 4. LU Ses- 


Manager" for details of how 


session-level pacing is set up before these 
flows occur. 


(receiver ) 
NWS RPC 
1 0 

0 
0 0 
2 0 
0 1 
3 1 
3 0 
0 2 
2 2 
2 1 
2 0 
0 1 
0 0 

queue is not empty when this IPM is 


received, so the RLWI is set to RLW in 
the next pacing request sent. 


The first request in a window has the 
Pacing indicator set to PAC. The Request 
Larger Window indicator is set to RLW 
(determined when the last solicited IPM 
was received). 


The receiver increases the sender's next 
window to 3. 


This is not the first RU in a window so 
the Pacing indicator is set to ~PAC. 


a, 


“ 
{ 


( ) 


increases the sender's next-window size 
according to the availability of its 
buffer storage. The sender's residual 
pacing count was not at 0 when this IPM 
was received, so the RLWI will be set to 
“RLW in the next pacing request sent. 


The first request in a window sets the 
Pacing indicator to PAC. The RLWI is set 
to ~RLW (determined when the last solic- 
ited IPM was received). 


(receiver ) 


7 7. The solicited IPM is received. The send- 
( 7 er's residual pacing count was at 0, but 
J the pacing queue was empty when this IPM 
Ries was received, so the RLWI will be set to 
“RLW in the next pacing request sent. 
8. The first request in a window sets the 
Pacing indicator to PAC. The RLWI is set 10. 
to -RLW (determined when the last solic- 
ited IPM was received). 
9. The receiver decreases the sender's next 
window to 2. (The receiver decreases or 
(sender ) 
NWS RPC NWS 
3 0 3 
RQ,PAC,-RLW 
: 1 0 2 OO 0 
4 IPM (unsolicited, NWS=0) 
Sa 2 0 
RQ,-~PAC 
3 8) 1 > 0 
G 0 0 < 
IPM (reset acknowledgment ) 
5 0 0 ——— Oe > 0 
IPM (solicited, NWS=2) 
6 2 0 < 2 
IPM (unsolicited, NWS=0) 
7 2 
_ RQ,PAC,RLW 
J 8 0 1 ——___—_ > 0 
/ 
9 0 0 < 
IPM (reset acknowledgment ) 
10 0 0 —— oo 0 
IPM (solicited, NWS=1) 
ll 1 0 < 1 
LEGEND 
per. 
f NWS next-window size 
= RPC residual pacing count 
RQ request 
PAC Pacing indicator set to 1 
~PAC Pacing indicator set to 0 
RLW Request Larger Window indicator set to 1 
-RLW Request Larger Window indicator set to 0 


Figure 6.2-5. 


The comments below correspond to the numbers 
in Figure 6.2-5 on page 6.2-11. 


1. 


2. 


The session has been active for a while. 


The first request in a window sets the 
pacing indicator to PAC. 


The receiver is congested and sends an 
unsolicited IPM with a next-window size 
of 0. 


Session-Level Pacing with Unsolicited IPMs 


Chapter 6.2. 


RPC 
0 


2 


The sender sends, and the receiver 
receives, another request before the 
unsolicited IPM arrives at the sender. 


The sender receives the unsolicited IPM 
causing it to reset its residual pacing 
count, use the value 0 in the IPM for its 
next-window size, and send ae reset 
acknowledgment IPM. The sender cannot 
send anything more until it receives 
another IPM. 


When the IPM reset acknowledgment is 


received, the receiver can then free the 
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buffers (1 in this case) that were not 
used by the sender by resetting the resi- 
dual pacing count to 0. By having sent 
an unsolicited IPM with a next-window 
size of 0, the reset acknowledgment IPM 
acts as a request by the sender to allow 
it to send a new window; when the receiv- 
er node is no longer congested, it will 
send a solicited IPM to the sender. 

7. The sender is restarted when it receives 
a solicited IPM with a next-window size 
of 2. 


8. The receiver goes back into a congested 
state shortly after sending the solicited 
IPM, and sends an unsolicited IPM. The 
unsolicited IPM specifies a next-window 
size of 0. 


9. The sender sends, and (the receiver 
receives, a request before the unsolicit- 
ed IPM is received. The receiver ignores 
the Pacing indicator because an unsolic- 
ited IPM is outstanding. 


10. The sender receives the unsolicited IPM 
causing it to reset its next-window size, 
use the value (0) in the IPM for its 
next-window size, and send aée reset 
acknowledgment IPM. The sender cannot 
send anything more until it receives 
another IPM. 


11. When it receives the reset acknowledgment 
IPM, the receiver can free the buffers 
(1, in this case) that were not used by 
the sender by resetting the residual pac- 
ing count to 0. 


12. The sender is restarted when it receives 


a solicited IPM with a next-window size 
of 1. 


Session-Level Fixed Pacing Algorithm 


The session-level fixed pacing algorithm is 
similar to the adaptive pacing algorithm, but 
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with the following differences: 


1. The buffer manager always generates the 
same fixed number for the next-window 
size, as determined at session activation 
time. 


2. When the receiver would generate an IPM, 
it generates an IPR or a “piggybacked" 
pacing response instead. | | 


3. The sender saves the value for the fixed 
window size determined at session acti- 
vation time. 


G4. The sender receives an IPR instead of an 
IPM and takes its next-window size to be 
the value it saved at session activation 
time. 


5. The buffer manager cannot cause an unso- 
licited IPM to be sent. The window size 
is fixed and IPR is always sent as a 
solicited pacing response. 


SEGMENT REASSEMBLY FUNCTION 


Conceptually, segment reassembly is a path 
control (PC) function; however, the inbound 
segment reassembly function is modeled in 
this book (see page 6.2-28). If the 
half-session supports segment reassembly, it 
reassembles segments (associated with the 
same BIU) into a whole BIU. When segments 
are received, the half-session checks for the 
max imum receive RU size (See 
TC .SEGMENT_RCV_CHECKS (page 6.2-24)). 


See SNA Type 2.1 Node Reference for more 


C 


FORMAL DESCRIPTION 


C. 
~ 


TC. INITIALIZE 


FUNCTION: This procedure sets up session parameters needed by TC. 


This procedure is called by the half-session initialization procedure (see 
Chapter 6.0) when the session is being activated. The LOCAL data structure 
fields that are used only by TC are initialized by this procedure. 


INIT_HS from SM, containing BIND information 
| ( The LOCAL fields used only by TC are initialized 
~~ - The identifier of the path control with which this half-session is associated, 
the role (primary or secondary) of the half-session, and LOCAL.SENSE_CODE are 


initialized prior to calling this procedure. 


LOCAL.SENSE_CODE is set to X'00000000' by called routines, if the TC initial- 
ization was successful. Otherwise, it is set to a nonzero sense data value by 
called routines. 


. RCV_PACING.NWS is not set to 0 by SM in any case. Send pacing queue (Q_PAC) 
should be created in this procedure. This queue is used to send normal-flow 
requests to path control. 


eS Referenced procedures, FSMs, and data structures: 
| HS page 6.0-3 
TC .EXCHANGE_CRV page 6.2-15 
LOCAL page 6.0-7 
INIT_HS page A-13 


If this is a primary half-session then 

Set LOCAL.MAX_RCV_RU_SIZE to INIT_HS.SHORT_BIND_IMAGE.SEC_SEND_MAX_RU_SIZE. 
Else (secondary half-session) 

Set LOCAL.MAX_RCV_RU_SIZE to INIT_HS.SHORT_BIND_IMAGE.PRI_SEND_MAX_RU_SIZE. 
Set LOCAL.SQN_RCV_CNT to 0. 


: Initialize LOCAL.COMMON_CB fields to the following values: 
WY Set CALLER to HS, LFSID to INIT_HS.LFSID. 
Set PATH_CONTROL_ID to INIT_HS.PATH_CONTROL_ID. 
Set DYNAMIC_BUFFER_POOL_ID to INIT_HS.DYNAMIC_BUFFER_POOL_ID. 
Set LIMITED _BUFFER_POOL_ID to INIT_HS.LIMITED_BUFFER_POOL_ID. 
Set TRANSMISSION_PRIORITY to INIT_HS.TRANSMISSION_PRIORITY. 
Set NUM_BUFS_PER_RU to 1, SET_RLWI to -RLH. 
Set SEND_PACING.RPC and RECEIVE _PACING.RPC to 0. 
If this is a primary half-session then 
Set SEND_PACING.NWS to INIT_HS.SHORT_BIND_IMAGE.PRI_SEND_WINDOW_SIZE. 
Set RECEIVE_PACING.NWS to INIT_HS.SHORT_BIND_IMAGE.PRI_RCV_WINDOW_SIZE. 
Else (this is a secondary half-session) 
Set SEND_PACING.NWS to INIT_HS.SHORT_BIND_IMAGE .SEC_SEND_WINDOW_SIZE. 
Set RECEIVE_PACING.NWS to INIT_HS.SHORT_BIND_IMAGE.SEC_RCV_WINDOW_SIZE. 


4 
\ 
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Following are valid send/receive pacing type combinations: 


SENDER RECEIVER 


adaptive adaptive 
fixed fixed 
none fixed 


If INIT_HS.SHORT_BIND_IMAGE .ADAPTIVE_PACING = SUPPORTED then 
Set SEND_PACING.TYPE and RECEIVE_PACING.TYPE to ADAPTIVE 
Else 
Set RECEIVE_PACING.TYPE to FIXED. 
If LOCAL .COMMON_CB.SEND_PACING.NWS > 0 then 
Set SEND _PACING.TYPE to FIXED. 
Else 
Set SEND_PACING.TYPE to NONE. 
Set FIRST_WS to SEND_PACING.NWS. 
Set UNSOLICITED_IPM_OUTSTANDING to FALSE. 
Set ADJUST_FOR_IPM_ACK_OUTSTANDING to FALSE. 
Set UNSOLICITED_NWS to 0. 
Set RESERVE_FLAG to NO. 
If INIT_HS.SHORT_BIND_IMAGE .WHOLE_BIU_REQUIRED = YES then 
Set LOCAL.SEQMENTING_ SUPPORTED to FALSE. 
Else 
Set LOCAL.SEQMENTING_SUPPORTED to TRUE. 
Set LOCAL.CRYPTOGRAPHY to NO. 
If INIT_HS.SHORT_BIND_IMAGE .CRYPTO_SESSION_LEVEL = MANDATORY then 
Set LOCAL.CRYPTOGRAPHY to YES. 
Call TC.EXCHANGE_CRV(INIT_HS) (page 6.2-15) 
to exchange cryptography verification (CRV) information. 
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TC .EXCHANGE_CRV 


FUNCTION: This procedure handles the exchange of cryptography verification (CRV). 


This procedure is called from a_ primary half-session to initiate the exchange 
CRV request with a secondary and receive RSP(CRV), or called from a secondary 
half-session to receive CRV request from a primary and return RSP(CRV). 


INIT_HS, containing the enciphered pseudo-random value 


value (and later as the session seed) 


to be used as 


a test 


This value is enciphered using the session Key as the cryptography Key and 0 


as the initial chaining value. 


OUTPUT : LOCAL.SENSE_CODE is set to the sense data carried on the negative RSP(CRV), if 
CRV exchange failed; else it is set to X'00000000' 


The secondary half-session sends a RSP(CRV) to the primary. 


RSP(CRV), if CRV exchange successful; 


LOCAL .HALF_SESSION is initialized 


else a negative RSP(CRV) 


before this procedure 


A positive 


is called. 
LOCAL.SENSE_CODE may be changed by the procedures called from this procedure. 


The initialization of a primary TC instance involves sending an MU containing 


a CRV request and receiving an MU containing a_ RSP(CRV). 


of a secondary TC instance involves 


sending an MU containing a 


receiving an MU containing a CRV request. 


The initialization 
RSP(CRV) and 


The buffer that the CRV request was in is reused by secondary half-session 
(with appropriate RH bit settings) to send a RSP(CRV). 


Referenced procedures, FSMs,» and data structures: 
HS | 


TC.BUILD_CRV 
TC.CRV_FORMAT_CHECK . 


PATH CONTROL 


If primary half-session then 
Call TC.BUILD_CRV(INIT_HS,MU_PTR) (page 6.2-17) 
to build a CRV exchange request. 
Call SEND_MU(MU, LOCAL.COMMON_CB) (page 6.2-20) 
to send CRV exchange request to path control ( 


page 
page 
page 
page 
page 
page 
page 
T2.1 


to secondary half-session). 


Receive RSP(CRV) from path control (sent from secondary half-session). 


Call TC.CRV_FORMAT_CHECK(MU) (page 6.2-18). 
If LOCAL.SENSE_CODE = X'00000000' and MU.RH.RTI 
Set LOCAL.SENSE_CODE to the sense data carri 


= NEG then 
ed'on the negative RSP(CRV). 


Call buffer manager (FREE_BUFFER, buffer address) 


to release the buffer containing the RSP(CRV). 


(Appendix B) 
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TC .EXCHANGE_CRV 


Else (secondary half-session) 
Receive CRV request from path control (sent from primary half-session). 
Call TC.CRV_FORMAT_CHECK(MU) (page 6.2-18). 
If LOCAL.SENSE_CODE = X'00000000' then 


If 


(Check that the CRV test value was correctly encoded by the session partner ) 


Decipher the test value (bytes 2-9 of MU.RU). The cryptography Key is the 
session key, the initial chaining value is 0. 
Invert the bits in the first 4 bytes of the deciphered test value 
(i.e., exclusive-OR the deciphered test value with X' FFFFFFFFOO000000 * ie 
Compare the resulting value with the value 
that was generated by the session manager in the positive RSP(BIND). 
If values are not equal then 
Set LOCAL.SENSE_CODE to X'08350001' (indicating Invalid Parameter ). 
Else 
Set LOCAL.SENSE_CODE to X'00000000' (test value was correctly encoded by 
primary half-session). 


LOCAL.SENSE_CODE = X'00000000' then 
Set RH.RRI to RSP, RH.RTI to POS to indicate a positive response. 
Call SEND _MU(MU, LOCAL.COMMON_CB) (page 6.2-20) 
to send a positive RSP(CRV) to path control (to primary half-session). 


Else 


Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous CRV request. (Appendix B) 
(The half-session router will cause UNBIND to be sent. ) 
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TC.BUILD_CRV 


FUNCTION: This procedure builds an MU (containing the CRV request) by appropriately ini- 
tializing the TH, RH and RU fields. 


INPUT : INIT_HS, containing the enciphered pseudo-random value to be used as a test 
value 


OUTPUT : The address of the MU, it contains a CRV request 


The MU is initialized by this procedure (MU.RU contains the cryptography 
seed). 


For the actual TH and RH bit settings see SNA Formats. 


If a permanent buffer is not available,» a demand buffer is requested by this 
procedure instead. 


Both CRV request and RSP(CRV) are sent expedited. 


The session cryptography seed is retained from INIT_HS record. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
CRV_RQ_RU page A-27 
INIT_HS page A-13 
MU page A-29 


Call buffer manager (GET_BUFFER, permanent buffer pool ID», no wait) 
to request a permanent buffer to build an MU. (Appendix B) 

If permanent buffer is not available then | 

Call buffer manager (GET_BUFFER, demand buffer size, no wait) 

to request a demand buffer. The demand buffer size is maximum RU size 
plus MU overhead. (Appendix B) 
If demand buffer is not available then 
Perform half-session ABEND processing. 


Initialize MU.TH reserved fields and constant fields. 

Set EFI to EXP, SNF to any 16-bit unique value (implementation-dependent). 
(CRV is sent expedited- rather than normal-flow, so is not related to the 
HS normal-flow send sequence number [LOCAL .SQN_SEND_CNT]. ) 

Set BBIUI to BBIU, EBIUI to EBIU. 

(Expedited-flow request [or response] should be sent as a whole BIU.) 


Initialize MU.RH reserved fields, constant fields and set the rest of 
RH bits to the following values: 
RQ, SC, FMH, -SD, BC, EC, RQD1, -RLW, -QR, ~PAC, -~BB, -CD, CODEO, -ED, ~PD, ~CEB 


Decipher the test value in the INIT_HS record. Use the session Key 
as the cryptography Key, and 0 as the initial chaining value. 
Transform the result by inverting the bits in the first four bytes (1.e., 
exclusive-OR the test value with X'FFFFFFFFOOO00000' ). 
Enciphering above transformed value. Use the session key as the cryptography Key 
and 0 as the initial chaining value. 
Set CRV_RQ_RU.CRYPTO_SEED to above enciphered value. 
Set RU to CRV_RQ_RU. (page A-27) 
Set the MU.DCF to indicate the length of RH and RU (CRV_RQ_RU). 
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TC .CRV_FORMAT_CHECK 


FUNCTION: This procedure checks the RH bits of the CRV request or RSP(CRV) received from 
path control (from the partner half-session). 


All of these checks are optional. An implementation may choose to do all, 
some, or none of them. 


INPUT: MU, containing a CRV request or RSP(CRV) 


OUTPUT: LOCAL.SENSE_CODE is set to X'00000000' if all RH bits are properly set; other- 
wise, it is set to a nonzero value which indicates error. 


Referenced procedures, FSMs» and data structures: 


HS page 6.0-3 
LOCAL page 6.0-7 
MU page A-29 
PATH CONTROL T2.1 Node Reference 


Calculate the length of RU data. 
If RRI = RQ then 
Select in the following order, based on the RH bits: 
When LOCAL.HALF_SESSION = PRI 
Set LOCAL.SENSE_CODE to X‘20090000'. 
When RU_CTGY # SC 
Set LOCAL.SENSE_CODE to X‘20090000'. 
When (SDI * SD and the length of RU data < 1) or 
(SDI = SD and the length of RU data < 5) 
Set LOCAL.SENSE_CODE to X'‘'10020000'. 
When (SDI # SD and CRV request code # X'CO') or 
(SDI = SD and CRV request code * X'CO') 
Set LOCAL.SENSE_CODE to X‘20090000'. 
When FI * FMH 
Set LOCAL.SENSE_CODE to X‘400FOO000'. 


A request containing sense code is an exception request. When path 
control receives an anonymous request and not be able to pass the 


response back to the anonymous request sender, path control sets the 
sense code and appends it to RU data to inform the receiver about the 
error. 


When SDI = SD 

Set LOCAL.SENSE_CODE to the sense code 

carried in the RU. 

When BCI # BC 

Set LOCAL.SENSE_CODE to X'400B0000'. 
When ECI # EC 

Set LOCAL.SENSE_CODE to X‘'400B0000'. 
When response category * RQD1 

Set LOCAL.SENSE_CODE to X‘'40140000'. 
When EFI # EXP 

Set LOCAL.SENSE_CODE to X'40110000'. 
When QRI = QR 

Set LOCAL.SENSE_CODE to X'40150000'. 
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When PI = PAC 
Set LOCAL.SENSE_CODE to X'40080000'. 
When BBI = BB 
Set LOCAL.SENSE_CODE to X'400C0000'. 
When EBI = EB 
Set LOCAL.SENSE_CODE to X'400C0000'. 
When CDI = CD 
Set LOCAL.SENSE_CODE to X'400D0000'. 
When CSI = CODE1 
Set LOCAL.SENSE_CODE to ‘40100000’. 
When EDI = ED 
Set LOCAL.SENSE_CODE to X'40160000'. 
When PDI = PD 
Set LOCAL.SENSE_CODE to X'40170000'. 
When CEBI = CEB 
Set LOCAL.SENSE_CODE to X‘400C0000'. 
Else (CRV response) 
Select in the following order, based on the RH bits: 
When LOCAL.HALF_SESSION = SEC 
Set LOCAL.SENSE_CODE to X'20090000'. 
When RU_CTGY * SC 
Set LOCAL.SENSE_CODE to X'20090000'. 
When (RTI = POS and the length of RU data < 1) or 
(RTI = NEG and the length of RU data < 5) 
Set LOCAL.SENSE_CODE to X'10020000'. 
When (SDI * SD and CRV request code # X'CO') or 
(SDI = SD and CRV request code # X'CO') 
Set LOCAL.SENSE_CODE to X'20090000'. 
When FI # FMH 
Set LOCAL.SENSE_CODE to X'4OOFOOQOO'. 
When BCI # BC 
Set LOCAL.SENSE_CODE to X‘'400B0000'. 
When ECI # EC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When EFI * EXP 
Set LOCAL.SENSE_CODE to X'40110000'. 
When DR1I # DR1 or DR2I = DR2 
Set LOCAL.SENSE_CODE to X'40140000'. 
When (RTI = POS and SDI = SD) or 
(RTI = NEG and SDI = NOT_SD) 
Set LOCAL.SENSE_CODE to X'40130000'. 
When QRI = QR 
Set LOCAL.SENSE_CODE to X'40150000'. 
When PI = PAC 
Set LOCAL.SENSE_CODE to X'40080000'. 
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SEND_MU 


FUNCTION: This procedure sends the input MU to path control. 


INPUT : MU, containing normal-flow or expedited-flow request (or response); 
LOCAL .COMMON_CB, containing appropriate pacing bits setting 


OUTPUT: = The MU is sent to PC or placed on Q_ PAC, if no errors are found. If send pac- 
ing is active, the send pacing counts in the CB may be updated. 


NOTES: 1. If pacing is supported, the MU may be placed on Q_PAC (send pacing queue) 
rather than sent directly to path control. 


If required the MU data is enciphered before sending out. 
The pacing counts in the LOCAL.COMMON_CB (page 6.0-8) are set before this pro- 


cedure is called. 


Referenced procedures, FSMs, and data structures: 


SEND_TO_PC . page 6.2-22 

MU | page A-29 

LOCAL Chapter 6.0 

PATH CONTROL T2.1 Node Reference 


Select, in the following order, based on the TH and RH bits: 
When TH.EFI = EXP (indicating the MU is sent expedited-flow) 
Call SEND_TO_PC(MU, LOCAL.COMMON_CB) (page 6.2-22) 
to send the MU to path control directly (expedited-flow is not paced). 
When TH.BBIUI = -BBIU or RH.RRI = RQ (normal-flow request) 
If RH.RU_CTGY=FMD, RU data is present and cryptography is required then 
If the RU length is not an even multiple of 8 then 
Pad the RU to an integral number of eight bytes. The padding bytes are 
padded to the end and contain unpredictable values, except for the last 
pad byte, which contains an unsigned 8-bit binary count of the pad bytes 
preceding it. If only one byte of pad is required, it is the count byte 
itself and contains 1. 
Set RH.PDI to PD (indicating pad character string is present). 
Else (multiple of 8) 
Set RH.PDI to -PD. 


Encipher the RU data. 
(Execute the Data Encryption Standard [DES] algorithm, using the session Key 
as the cryptography Key and the session seed as the initial chaining value. 
The manner in which the session Key and the session seed are made available 
to this procedure is implementation-defined. ) 
If data enciphering fails then 
Set LOCAL.SENSE_CODE to X'08480000' (cryptography function inoperative). 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous MU. (Appendix B) 
Else 
Set LOCAL.SENSE_CODE to X'00000000'. 
Set RH.EDI to ED (indicating RU data is enciphered). 
If LOCAL.COMMON_CB.SEND_PACING.TYPE # NONE (indicating pacing is active) then 
If the Q_PAC contains any MUs or TH.BBIUI = BBIU then 
If the sum of LOCAL.COMMON_CB.SEND_PACING.RPC and 
LOCAL .COMMON_CB.SEND_PACING.NWS is 0 then 
Put the request MU on the pacing queue (the send pacing count 
has gone to zero). 
Else 
Call SEND_TO_PC(MU, LOCAL.COMMON_CB) (page 6.2-22). 


When RRI = RSP | 
If LOCAL .COMMON_CB.SEND_PACING.TYPE = NONE or 
the Q PAC does not contain any MUs or 
QRI = -QR’- then 
Call SEND_TO_PC(MU, LOCAL.COMMON_CB) (page 6.2-22). 
Else 
Put the response MU on the send pacing queue. 
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C SEND_PACING 


FUNCTION: This procedure updates the send pacing counts in the common control block and 
sets the pacing bits (RH.PI and RH.RLWI of the MU being sent) to the appropri- 
ate value. 


This procedure will never be called when both the residual pacing count and 
the next window size are 0 (see page 6.2-20). 


INPUT: MU, containing a normal-flow request (beginning BIU); LOCAL.COMMON_CB, con- 
taining appropriate pacing bits setting 


OUTPUT: The pacing bits in the request MU may be changed; the SET_RLWI bit and pacing 
counts in the LOCAL.COMMON_CB may be changed. 


Referenced procedures, FSMs» and data structures: 


MU page A-29 
LOCAL Chapter 6.0 
e : If LOCAL.COMMON_CB.SEND_PACING.RPC > 0 then 


Decrement LOCAL.COMMON_CB.SEND_PACING.RPC by 1. 
Else (start the next window) 
Set LOCAL .COMMON_CB.SEND_PACING.RPC to (LOCAL.COMMON_CB.SEND_PACING.NWS - 1). 
Set LOCAL .COMMON_CB.SEND_PACING.NWS to QO. 
Set PI to PAC (to show a pacing response is required). 
Set MU.RLWI to LOCAL.COMMON_CB.SET_RLWI (SET_RLWI value was stored in the 
LOCAL.COMMON_CB when the pacing response was received). 
Reset LOCAL.COMMON_CB.SET_RLWI to -RLW. 


Co 
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SEND_TO_PC 


FUNCTION: This procedure sends an MU to path control. 


INPUT: MU, LOCAL .COMMON_CB 


OUTPUT: The input MU is~ sent to path control with the HS_TO_PC header filled in and, 
if necessary, the send pacing counts in LOCAL.COMMON_CB may also be updated. 


Referenced procedures, FSMs, and data structures: 


SEND_PACING | page 6.2-21 

MU page A-29 

IPM_RU page 6.2-33 

LOCAL | Chapter 6.0 

PATH CONTROL T2.1 Node Reference 


Set MU.HEADER_TYPE to HS_TO_PC. 


Fill in HS_TO_PC header with the LFSID and TRANSMISSION PRIORITY | = 
values from the LOCAL .COMMON_CB \ | 
(TRANSMISSION PRIORITY indicates the priority of the session). Smee 


If this is the beginning of a BIU (BBIUI = BBIU) then 
If this MU contains an IPM (MU.RH.RRI=RSP, RH.PI=PAC, ~DR1, -DR2 and 
LOCAL .COMMON_CB.SEND_PACING.TYPE is ADAPTIVE then 
If IPM_RU.TYPE is not set to indicate an IPM reset acknowledgement then 
Set HS_TO_PC.TRANSMISSION_ PRIORITY to NETWORK. 
(Solicited or unsolicited IPM flows at network priority). 
Else (MU doesn't contain an IPM) 
If this 1s a normal-flow request and 
is being paced (LOCAL.COMMON_CB.SEND_PACING.TYPE #* NONE) then 
Call SEND_PACING(MU, LOCAL.COMMON_CB) (page 6.2-21). 


_ 
Send the MU to path control. C > 
If sending MU failed (1.e., the path control doesn't exist any more) then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
that the MU was in. (Appendix B) 
(The session will be brought down soon by SM). 
a 
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FUNCTION: 


INPUT: 


OUTPUT : 


TC.RCV 


This procedure receives MUs sent from path control. 
The format and state checks are made in this procedure. 


MU, containing a request or response is received from the HS router (see Chap- 
ter 6.0) 


If a pacing response is received, it is processed in TC and will not be passed 
to DFC. TC updates the send pacing counts in the LOCAL.COMMON_CB and the pac- 
ing response is discarded; else, DFC is called to receive and process the MU 


If the RU data (received from path control process) has been segmented, the 
segments are reassembled in this procedure. The data that goes out (from 


half-session process) is not segmented. 


The receive pacing counts in the CB may be changed according to the pacing 


bits (RH.PI, RH.RLW) setting in the request. 


Upon receiving the request MU, the sequence number (LOCAL.SQN_RCV_CNT) may be 


updated. 


If an error is encountered, LOCAL.SENSE_CODE is set to a nonzero value by a 
called routine, the HS router causes an UNBIND to be generated; otherwise, it 


is set to X'00000000'. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
TC .DECIPHER_RU page 6.2-32 
TC ..SEGMENT_RCV_CHECKS page 6.2-24 
SEGMENT_REASSEMBLY page 6.2-28 
TC.BIU_RCV_CHECKS page 6.2-25 
RECEIVE _PACING page 6.2-27 
RCV_PACING_RSP page 6.2-29 
DFC_RCV page 6.1-24¢ 
LOCAL page 6.0-7 
MU page A-29 
PATH CONTROL T2.1 Node Reference 


Call TC.SEGMENT_RCV_CHECKS(MU) (page 6.2-24). 
If LOCAL.SENSE_CODE = X'00000000' then 
If normal-flow request and BBIUI = BBIU then 
Call RECEIVE PACING(MU, LOCAL.COMMON_CB) (page 6.2-27) 
If normal-flow (request or response) MU then 
If (request MU and BBIUI = BBIU) or (BBIUI = -BBIU) then 
Call SEGMENT_REASSEMBLY( the MU address) (page 6.2-28). 
If LOCAL.SENSE_CODE = X'00000000' then 
If a reassembled MU is present then 
Call TC.BIU_RCV_CHECKS(MU) (page 6.2-25). 
If LOCAL.SENSE_CODE = X'00000000' then 
If normal-flow request then 
If cryptography is required, RU data is present, 
RH.RU_CTGY = FMD and no sense data is present then 
Call TC.DECIPHER_RU(MU) (page 6.2-32). 
If LOCAL.SENSE_CODE = X'00000000' then 
If LOCAL.SQN_RCV_CNT = 65535 then 
(max sequence number is [2%**16 - 1]) 
Set LOCAL.SQN_RCV_CNT to 0. (sequence number wrapped) 
Else 
Increment LOCAL .SQN_RCV_CNT. by 1. 
Call DFC_RCV(MU) (page 6.1-24). 
Else 
If response MU and RH.PI = PAC then 
Call RCV_PACING_RSP(MU_PTR, LOCAL.COMMON_CB) 
(page 6.2-29) 
If an MU is present then 
Call DFC_RCV(MU) (page 6.1-24). 
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TC .SEGMENT_RCV_CHECKS 


FUNCTION: This procedure performs receive checks on all segments received from PC. 


INPUT: MU, containing a segment (perhaps the only segment in a BIU) 
OUTPUT: LOCAL.SENSE_CODE is set to reflect the receive checks. 


NOTE : Expedited-flow MU may not be segmented. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
MU_PACING CHECKS page 6.2-26 
LOCAL page 6.0-7 
MU | page A-29 


Select, in the following order, based on the following conditions: 


When -LOCAL.SEGMENTING_SUPPORTED and MU contains one of the segments (-[BBIU and EBIU]) 
Set LOCAL.SENSE_CODE to X'‘'80070001' (receipt of segment not supported). 
When BBIU, ~EBIU, ~(NORMAL, RQ) 
Set LOCAL.SENSE_CODE to X'80070003' (cannot reassemble response or expedited-flow 
request). 
When NORMAL, RQ, BBIU and segment reassembly is in progress 
Set LOCAL.SENSE_CODE to X‘80070000' (BBIU segment not preceded by EBIU segment). 
When -BBIU and (segment reassembly is not in progress or this MU flows expedited) 
Set LOCAL.SENSE_CODE to X'80070000' (-BBIU segment not preceded by BBIU segment). 
When -BBIU and MU.TH.SQN (in the BBIU segment) # MU.TH.SQN (in the -BBIU segment) 
(~BBIU segment has a sequence number different from the BBIU segment's 
sequence number. ) 
Set LOCAL.SENSE_CODE to X'80070000'. 
When BBIU, -EBIU and DCF < 10 (first in segment must have at least 10 bytes) 
Set LOCAL.SENSE_CODE to X'80070000'. 


If BBIU, LOCAL.SENSE_CODE = x'00000000' then 
Call MU_PACING_CHECKS(MU, COMMON_CB, LOCAL.SENSE_CODE) (page 6.2-26). 
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TC.BIU_RCV_CHECKS 


| 
it 
ae 


FUNCTION: This procedure performs receive checks on BIUs. 


INPUT : MU, containing a BIU 


OUTPUT: LOCAL.SENSE_CODE is set to reflect the receive checks. 


NOTE : LOCAL.CRYPTOGRAPHY is properly set before this procedure is called. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
LOCAL page 6.0~-7 
MU page A-29 
PATH CONTROL T2.1 Node Reference 


If MU.RH.RU_CTGY is not set to FMD or DFC then 
7 Set LOCAL.SENSE_CODE to X'10070000'. 
a Else (FMD or DFC) 
a , Set RU length to 0 (If RU data is not present in the receiving MU, 
a then 0 is the minimum RU length). 
If sense data is present (MU.RH.SDI = SD) then 
Increment RU length by 4 (the length of sense data). 
If MU.RH.RU_CTGY = DFC then 
Increment RU length by 1 (the length of request code). 
If DCF < length of (RU + RH) then 
Set LOCAL.SENSE_CODE to X'10020000'. 
Else 
If sense data is present then 
If received MU contains a request then 


( : A request containing a sense code is an exception request. When path 
Na ol? control receives an anonymous request and is not be able to pass the 


response back to the anonymous request sender, path control sets the 
sense code and appends it to RU data to inform the receiver about the 
error. 


Set LOCAL.SENSE_CODE to the sense data from input MU. 
Else 
If normal-flow request then 
If sequence number from the input MU does not match 
current sequence number (LOCAL.SQN _RCV_CNT + 1) then 
aes (The current sequence number must be a multiple of 65536.) 

C Set LOCAL.SENSE_CODE to X'20010000' (sequence number check). 
aoe 


If cryptography is active then 
If MU.RH.RU_CTGY = FMD then 
If RU data is present and LOCAL.SENSE_CODE = X'00000000' then 
If encryption bit is not set (RH.EDI = -ED) then 
Set LOCAL.SENSE_CODE to X‘'08090000'. 
Else 
If RU data length is not a multiple of 8 then 
Set LOCAL.SENSE_CODE to X'10010000'. 
(the maximum RU size must be a multiple of 8) 


i 
} 
“ z. 
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MU_PACING_CHECKS 


FUNCTION: This procedure performs the format checks for pacing responses and checks that 
the receive pacing counts are acceptable for begin BIU normal-flow requests. 


This procedure is called only when the BBIUI bit in TH is set to BBIU. The 


checks in this procedure are required checks. 


INPUT: MU, LOCAL .COMMON_CB 


OUTPUT: LOCAL .SENSE_CODE is set if an error is found; else, remains unchanged 


Referenced procedures, FSMs, and data structures: 


If normal-flow request then 
If LOCAL.COMMON_CB.RECEIVE_PACING.RPC = 0 then 

If LOCAL.COMMON_CB.RECEIVE_PACING.NWS = 0 then 
Set LOCAL.SENSE_CODE to X'‘'20110000°. 
(Sending node has overrun the pacing count. ) 

Else 
If pacing indicator is set to ~PAC (PI = ~PAC) then 

Set LOCAL.SENSE_CODE to X'20110000'. 


Else 
If pacing indicator is set to PAC (PI = PAC) then 
Set LOCAL.SENSE_CODE to X'20110002'. 
(In -first request in a new window, PI should be set to ~PAC) 
Else (response) 
If adaptive pacing is being used and 
the MU contains a response with pacing indicator set to PAC then 
If this MU is an IPM (RSP, -DR1, -DR2) then 
If MU.DCF contains a length that is too short for 
an IPM (RH + IPM_RU) then 
Set LOCAL.SENSE_CODE to X‘'10020000'. 
Else 
If IPM_RU.FORMAT_INDICATOR is not set to FORMATO then 
Set LOCAL.SENSE_CODE to X'10010003'. 
Else | 
Select, based on IPM_RU.TYPE: 
When SOLICITED IPM 
If IPM_RU.NWS = 0 or IPM_RU.RWI = RESET_WINDOW then 
Set LOCAL.SENSE_CODE to X'10010003'. 
Else 
If LOCAL.COMMON_CB.SEND_PACING.NWS > 0 then 
Set LOCAL.SENSE_CODE to X'20110001'. 
When UNSOLICITED IPM 
If IPM_RU.RWI = -RESET_WINDOW then 
Set LOCAL.SENSE_CODE to X'10010003'. 
When RESET_ACKNOWLEDGEMENT IPM 
If ~LOCAL.COMMON_CB.UNSOLICITED_IPM_OUTSTANDING then 
Set LOCAL.SENSE_CODE to X'20110001'. 
Otherwise (invalid IPM type) 
Set LOCAL.SENSE_CODE to X‘'10010003'. 
Else (this is not an IPM) 
Set LOCAL.SENSE_CODE to X‘20110003'. 
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(In the first request of a new window, PI should be set to PAC. 


page A-29 
page 6.2-33 
Chapter 6.0 


} 


acne 


RECEIVE _PACING 


FUNCTION: 


INPUT: 


OUTPUT: 


RECEIVE PACING 


This procedure updates the receive pacing counts in the LOCAL.COMMON_CB and 
determines the type of buffer reserve action to request of the buffer manager. 
This procedure is never called when the residual pacing count and _ the 
next-window size are both QO. 


MU, LOCAL .COMMON_CB 


The receive pacing counts and the RESERVE_FLAG in the LOCAL.COMMON_CB may be 
changed. 


Referenced procedures, FSMs» and data structures: 


MU 


page A-29 


LOCAL Chapter 6.0 


If pacing indicator in the RH is not set to PAC then 
(Current window is not exhausted. ) 


LOCAL .COMMON_CB.RECEIVE_PACING.RPC by 1. 


Ree Decrement 
( | Set LOCAL.COMMON_CB.RESERVE_FLAG to NO (don't reserve a new window). 
ae Else (this is the first request in a new window) 
Set LOCAL .COMMON_CB.RECEIVE_PACING.RPC to LOCAL .COMMON_CB.RECEIVE_PACING.NWS minus 1. 
Set LOCAL .COMMON_CB.RECEIVE_PACING.NWS to 0. 
If larger window is required (RH.RLWI = RLW) then 
Set LOCAL .COMMON_CB.RESERVE_FLAG to MORE (request a larger new window). 


Else 


Set LOCAL .COMMON_CB.RESERVE_FLAG to ALL (request a new window). 
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SEGMENT_REASSEMBLY 


FUNCTION: This procedure copies normal-flow request MUs from link buffer to dynamic 
buffer. If segment reassembly is supported, this procedure is called to reas- 
semble segments into a whole BIU. 


INPUT: A pointer to MU (the MU contains a segment that received from path control) 


OUTPUT : When segment reassembly is complete, all segments (for the same BIU) are reas- 
sembled and stored in the dynamic buffer. The dynamic buffer address is 
returned to the calling procedure. If there is an IPM reset acknowledgment 
outstanding, dynamic buf fer pool may be adjusted and 
ADJUST_FOR_IPM_ACK_OUTSTANDING bit in the LOCAL.COMMON_CB may be changed. If 
an error is detected, LOCAL.SENSE_CODE is set to indicate the error 


SM reserves the first buffer for HS. 


MUs received from path control are stored in link buffers. A link buffer is a 
special type of permanent buffer that the buffer manager allocates to DLC to 
send network data between two LUs. The receiving LU calls buffer manager to 
get a dynamic buffer to copy data from the link buffer to dynamic buffer, and 
releases the link buffer. The dynamic buffer size is set to maximum RU size 
by SM at buffer pool create time. (See Appendix B for details. ) 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
SM | page 4-48 
LOCAL page 6.0-7 
MU page A-29 
PATH CONTROL T2.1 Node Reference 
If TH.BBIUI = BBIU then ge 
If RU length of the input MU is greater than the maximum RU size then ( 
Set LOCAL.SENSE_CODE to X'10020000' (RU length in error). x 


Else 
Call buffer manager (GET_BUFFER, dynamic buffer pool ID, no wait; 

buffer rereserve indication) to get a dynamic buffer for segment reassembly. 

Copy MU data from link buffer to dynamic buffer. (Appendix B) 
Call buffer manager (FREE_BUFFER, link buffer address) to release the link buffer 
containing the MU. (Appendix B) 

Else (TH.BBIU * BBIU) 

(The segments are reassembled in the same order they are received, i.e., the starting 
offset of the 2nd segment is immediately after the first segment. ) 
If ending offset of a segment is greater than the maximum receive RU size than 


Set LOCAL.SENSE_CODE to X‘10020000'. yrs 
Else 
Update the MU.DCF after each data copy (from link buffer to dynamic buffer). 5 ae 


Call buffer manager (FREE_BUFFER, link buffer address) to release 
the link buffer containing the MU. (Appendix B) | 


If reassembly is complete (TH.EBIUI = EBIU) then 
Set TH.EBIUI to EBIU. 
(When the first segment was copied from link buffer 
to dynamic buffer, the whole segment [containing TH, RH and RU] 
was copied. The TH bits setting indicates BBIU and -EBIU. When the 
second segment arrives, only the RU portion was copied to dynamic buffer 
not TH and RH. If the second segment is the last segment for this BIU, 
after copying the RU this procedure needs to update the TH bits setting to 
indicate EBIU. ) ? 


If LOCAL .COMMON_CB.ADJUST_FOR_IPM_ACK_OUTSTANDING is set to TRUE then 
Call buffer manager (ADJUST_BUF_POOL, dynamic buffer pool ID, REDUCED 
pool size) to reduce the size of the dynamic buffer pool. 
The REDUCED pool size is sent by the buffer manager via a BUFFERS_RESERVED signal. 
(Appendix B) | : - 
Set LOCAL.COMMON_CB.ADJUST_FOR_IPM_ACK_OUTSTANDING to FALSE. ¢ 


Return the address of the dynamic buffer to the calling procedure. 
(The dynamic buffer contains the reassembled whole BIU. ) 
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RCV_PACING_RSP 


FUNCTION: This procedure updates pacing counts in the LOCAL.COMMON_CB, sends reset 
acknowledgments to unsolicited IPMs and sends MUs to path control if possible. 


INPUT: A pointer to the MU; LOCAL.COMMON_CB, the common control block for the pacing 
routines | 


OUTPUT: The pacing response is discarded after being processed and the MU is freed; 
LOCAL .COMMON_CB, the pacing counts, SET_RLWI, UNSOLICITED_IPM_OUTSTANDING, and 
ADJUST_FOR_IPM_ACK_OUTSTANDING may be updated; IPM ACK may be sent’ to path 
control; MUs from the pacing queue sent to path control; the dynamic buffer 
pool and the limited buffer pool sizes may be adjusted 


: Referenced procedures, FSMs, and data structures: | 

) SEND_TO_PC page 6.2-22 
IPM_RU page 6.2-33 
LOCAL Chapter 6.0 
MU page A-29 


Select, in the following order, based on the pacing type: 
When adaptive pacing 
Select, based on the type of IPM_RU: 
When reset acknowledgment IPM 
Set LOCAL.COMMON_CB.RECEIVE_PACING.RPC to 0. 
Set LOCAL.COMMON_CB.RECEIVE_PACING.NWS to 
LOCAL .COMMON_CB.UNSOLICITED_NWS (the next window size 


fo carried in the previous unsolicited IPM). 
C Set LOCAL.COMMON_CB.UNSOLICITED_IPM_OUTSTANDING to FALSE. 
a Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 


containing the reset acknowledgment IPM. (Appendix B) 
If segment reassembly is not in progress then 
Call buffer manager (ADJUST_BUF_POOL, dynamic buffer pool ID, REDUCED 
pool size) to adjust the dynamic buffer pool size to the size informed by 
the buffer manager (via a BUFFERS_RESERVED signal). 
(Appendix B) | 
Else (segment reassembly is taking place) 
Set LOCAL .COMMON_CB.ADJUST_FOR_IPM_ACK_OUTSTANDING to TRUE . 


When solicited IPM 
‘i If data waiting on the pacing queue (Q_PAC) to be sent then 
( ; If LOCAL.COMMON_CB.SEND_PACING.RPC = 0 then 
— (the queued data is waiting for the NWS carried in this IPM) 
Set LOCAL.COMMON_CB.SET_RLWI to RLW. 
(Request a larger window on the next pacing request. ) 
Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to increase the size of the limited buffer pool based on IPM_RU.NWS. The 
change amount is IPM_RU.NWS. (Appendix B) 
Set LOCAL.COMMON_CB.SEND_PACING.NWS to IPM_RU.NWS. 
Call buffer manager (FREE_BUFFER, buffer address) to release the 
buffer containing the solicited IPM. (Appendix B) 


C > 
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When unsolicited IPM 
Call buffer manager (GET_BUFFER, permanent buffer pool ID, no wait) & 
to request a permanent buffer to store the unsolicited IPM. C 
(Appendix B) 
If permanent buffer is not available then 
Call buffer manager (GET_BUFFER, demand, buffer size, no wait ) 
to request a demand buffer to store the unsolicited IPM 
If demand buffer is not available then 
Perform half-session ABEND processing. 

Copy MU data from the link buffer (the unsolicited IPM was in) to 

the permanent (or demand) buffer. 
Call buffer manager (FREE_BUFFER, link buffer address) 

to release the link buffer containing unsolicited IPM. 
Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 

to reduce the size of the limited buffer pool to no buffers. 

The change amount is a negative value of (NWS plus RPC). 

(Appendix B) 
Set LOCAL .COMMON_CB.SEND_PACING.NWS to IPM_RU.NWS. 
Reset LOCAL .COMMON_CB.SEND_PACING.RPC to 0. 
Set IPM_RU.TYPE to RESET_ACKNOWLEDGMENT. 
Set IPM_RU.RWI to ~RESET_WINDOW. 
Call SEND_TO_PC (page 6.2-22) | 7 

to send reset acknowledgment IPM to path control (to the oo LU). C 


When no pacing 
If -DR1,-DR2 (received MU is a pacing response) then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the erroneous MU. 


When fixed pacing 
Set LOCAL.COMMON_CB.SEND_PACING.NWS to LOCAL.COMMON_CB.SEND_PACING.FIRST_WS. 
If -~DR1,-DR2 (received MU is a pacing response) then 
Call buffer manager (FREE_BUFFER, buffer address) to release the buffer 
containing the pacing response. 

Call buffer manager (ADJUST_BUF_POOL, limited buffer pool ID, change amount) 
to increase the size of the limited buffer pool. The change amount is OS 
LOCAL .COMMON_CB.SEND_PACING.FIRST_WS. (Appendix B) a 

eS 


If LOCAL.COMMON_CB.SEND_PACING.TYPE # NONE then 
Do the following while the pacing queue is not empty and the first MU is not a BBIU 
or the first MU is a response or | 
(LOCAL .COMMON_CB.SEND_PACING.RPC + LOCAL .COMMON_CB.SEND_PACING.NWS) >0. 


Remove the next MU from Q_PAC (pacing queue). 
Call SEND_TO_PC (MU, LOCAL.COMMON_CB) to send the MU just removed from pacing queue. 


—_ 


y 
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| < BUFFERS _RESERVED_PROCESSING 


| FUNCTION: This procedure receives BUFFERS_RESERVED signals from the buffer manager (BM), 
updates the appropriate pacing counts in the LOCAL.COMMON_CB, builds and sends 
the appropriate pacing response. 


The BUFFERS_RESERVED signal will have a reserve action of REDUCED, REPLEN- 
ISHED, or RESTART (reserve action of ADJUSTED will never be received by this 
routine); REDUCED is for an unsolicited IPM, while REPLENISHED and RESTART are 
for solicited IPMs 


INPUT: BUFFERS_RESERVED signal, LOCAL .COMMON_CB 


OUTPUT: The pacing counts in the LOCAL.COMMON_CB are updated; pacing response is sent 
to the appropriate path control 


Referenced procedures, FSMs» and data structures: 


sat SEND_TO_PC page 6.2-22 
LOCAL Chapter 6.0 
: PATH CONTROL T2.1 Node Reference 
= MU page A-29 
IPM_RU page 6.2-33 


If the reserved buffer pool size needs to be reduced (reserve action is assigned) then 
Set LOCAL.COMMON_CB.UNSOLICITED_IPM_OUTSTANDING to TRUE. 
Set LOCAL.COMMON_CB.UNSOLICITED_NWS to the value (as 
received in the BUFFERS_RESERVED signal) that will be sent in the IPM. 
Set MU.DCF for a unsolicited IPM (RH + IPM_RU). 
Set IPM_RU.TYPE to UNSOLICITED. 
Set IPM_RU.RWI to RESET_WINDONW. 
pe Set IPM_RU.FORMAT_INDICATOR to FORMATO. 
C Set IPM_RU.NWS to CB.UNSOLICITED NWS. 
“ Else (solicited IPM or IPR) 
Set LOCAL .COMMON_CB.RECEIVE_PACING.NWS to the value that will be sent in the IPM. 
If LOCAL.COMMON_CB.RECEIVE_PACING.TYPE = ADAPTIVE then 
Set MU.DCF for an solicited IPM (RH + IPM_RU). 
Set IPM_RU.TYPE to SOLICITED. 
Set IPM_RU.RWI to -~RESET_WINDON. 
Set IPM_RU.FORMAT_INDICATOR to FORMATO. 
Set IPM_RU.NWS to CB.RECEIVE_PACING.NWS. 
Else (an IPR) 
Set MU.DCF to the length of the RH (IPR contains no RU data). 


Set TH.EFI to EXP (this bit can be set to either expedited or normal for IPRs). 
Set TH.SNF.SQN to 0. 
Set RH bits to indicate the following: 
RSP, FMD, ~FMH, -SD, BC, EC, -DR1, ~DR2, POS, -RLW, -QR, PAC, -BB,» -EB, ~-CD, 
CODEO, “ED, -~PD, ~CEB. 
Call SEND_TO_PC(MU.LOCAL.COMMON_CB) (page 6.2-22) 
to send a pacing response (IPM or IPR) to path control. 


C— Set MU.TH bits to indicate BBIU, EBIU. 
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TC.DECIPHER_RU e 


FUNCTION: Deciphers an enciphered message. 


INPUT: Enciphered MU, session seed 


OUTPUT : Deciphered MU is returned or nonzero’ sense data is set in LOCAL .SENSE_CODE 5 
and if the MU was padded, pad bytes are dropped and Padded Data indicator set 
to -PD | 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
LOCAL page 6.0-7 
MU page A-29 


Decipher the RU data using the DES algorithm. Use the session Key 
as the cryptography Key. Use either the session seed or 0 as the : 
initial chaining value. If DES deciphering fails, the RC is set ( 
to NG; otherwise, OK. | oe. 


If DES deciphering RC = NG then 
Set LOCAL.SENSE_CODE to X'08480000' to indicate cryptography function inoperative. 
Else 
If PDI = PD (data was padded) then 
Save the length of RU data (MU.DCF - [the length of RH]). 
Extract the pad count from the last byte of the RU and assign it to PAD_COUNT. 
If (PAD_COUNT < 1) or (PAD_COUNT > 7) then 
Set LOCAL.SENSE_CODE to X'10010000' to indicate RU data length in error. 


Else 
Decrement MU.DCF by PAD_COUNT (drop pad bytes from RU). 
Set PDI to -PD. 7s 
LY 
Wee “ 
e™ 


— 
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IPM_RU 


This defines the RU format for an IPM 


IPM_RU 
TYPE: possible values: SOLICITED, UNSOLICITED, RESET_ACKNOWLEDGMENT 
RWI: possible values: RESET_WINDOW, NOT_RESET_WINDOW 
FORMAT_INDICATOR: possible value: FORMATO . 
NWS: next-window size : 
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aot APPENDIX A. NODE DATA STRUCTURES 
Co 
Pe, 


This appendix contains the shared data struc- 
tures for LU 6.2. 


LUCB 


The LUCB_LIST contains information about local LUs. One LUCB_LIST exists per node and one 
LUCB per local LU. 


* The LUCB_LIST is created at system-definition time. The initial values of the fields in 
es each LUCB entry are implementation-specific. 


NOTES: 1. Network-qualified LU names consist of type-A symbol strings. Transaction pro- 
gram names consist of type-AE up through type-GR symbol strings, depending on 
the implementation. See SNA Formats for symbol-string definitions. 


If the LU name is not present, the FULLY_QUALIFIED_LU_NAME field is null. 
Subarea LUs, LUs doing sync point, and LUs using parallel sessions always Know 
their own names. 


The FULLY _QUALIFIED_LU_NAME contains no trailing space (X'40') characters. 


oe \ LUCB 
a . 


LU_ID: identifier of the local LU 

FULLY_QUALIFIED_LU_NAME: network-qualified name of the local LU (see Notes) 
PARTNER_LU_LIST: list of PARTNER_LU data structures (see page A-2) 
TRANSACTION_PROGRAM_LIST: list of TRANSACTION_PROGRAM data structures (see page A-5) 
PENDING_RANDOM_DATA_LIST: list of random data (used for LU-LU verification) that 

has been sent on a BIND to a partner 


ee Data Unique to PS.COPR 


LU_SESSION_LIMIT: maximum number of LU-LU sessions the local LU can have 
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PARTNER_LU 


PARTNER_LU 


The PARTNER_LU_LLIST is a list contained within each LUCB entry. There is one PART- 
NER_LU_LIST per local LU and one PARTNER_LU entry for each LU name Known by a given local 
LU. Each PARTNER_LU entry contains information that is LU name specific (1i.e., informa- 
tion that is constant across all mode names for a given LU name). 


The PARTNER_LU_LIST is created at system-definition time. The initial values of the 
fields in each PARTNER_LU entry are implementation specific. | 


NOTES: 1. The (partner) LOCAL_LU_NAME is the name that a_ transaction program specifies 
in conjunction with the MODE_NAME when requesting the allocation of a conver- 
sation. It is a local name by which one local LU Knows another (partner) LU 
and is not sent outside the local LU. The maximum length of the LU_NAME is 
implementation-defined. 


There may be an entry in the PARTNER_LU_LIST whose LOCAL_LU_NAME is the same 
as the LU name of this (local) LU. This allows for cases when the partner 
transaction program is located in the same LU as the local transaction pro- 
gram. 


Local LU names consist of type-G symbol strings. Fully-qualified LU names 
consist of type-A symbol strings. See SNA Formats for symbol-string defi- 
nitions. | 


The (partner) FULLY_QUALIFIED_LU_NAME is the LU name that is sent on external 
flows > e.g.» BIND. 


The LOCAL_LU_NAME and FULLY_QUALIFIED_LU_NAME fields contain no trailing space 
(X'40') characters. 


PARTNER_LU C* 
Shared Data 


LOCAL_LU_NAME: local name of the partner LU (see Notes 1, 2, and 4) 
FULLY_QUALIFIED_LU_NAME: network-qualified name of the partner LU 
(see Notes 2, 3, and 4) 
MODE_LIST: list of MODE data structures (see page A-3) used with 
this partner LU | | 
ACTIVE_SESSION_PARAMETERS: 
PARALLEL_SESSIONS: possible values: SUPPORTED, NOT_SUPPORTED 


Nees 


C ) 
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MODE 


The MODE_LIST is a list contained within each PARTNER_LU entry. One MODE entry exists in 
the MODE_LIST for each mode name that is associated with PARTNER_LU.LOCAL_LU_NAME. Each 
MODE entry contains mode-name-specific information. 


The MODE_LIST is created at system-definition time. The initial values of the fields in 
each MODE entry are implementation specific. 


NOTES: 1. The WAITING_REQUEST_LIST contains requests for sessions sent by PS.CONV 
("Chapter 5.1. Presentation Services--Conversation Verbs") that the resources 
manager cannot presently fulfill, because no free sessions are available. 
Entries are removed from the list when an existing session becomes’ free or 
when a new session is activated. 


2. The FREE_SCB_LIST is a list of sessions that are currently not in use by any 
conversation. The list is an ordered list in that all first-speaker 
half-sessions are grouped at the front of the list with all bidder 
half-sessions following. A new first-speaker entry is inserted at the begin- 
ning of the list, while a new bidder entry is inserted at the end. 


The FREE_SCB_LIST and the WAITING_REQUEST_LIST are mutually exclusive. An 
entry in the FREE_SCB_LIST precludes there being an entry in the WAIT- 
ING_REQUEST_LIST, and vice versa. 


3. Mode names consist of type-A symbol strings. See SNA Transaction Programmer's 
Reference Manual for LU Type 6.2 for a list of valid symbol-string types for 
the Transaction program name. See SNA Formats for symbol-string definitions. 


4G. TERMINATION_COUNT is the count of the number of sessions that this local LU is 
responsible for deactivating. PENDING_TERMINATION_* counts sessions that are 
pending termination. A session is pending termination from the time that RM 
("Chapter 3. LU Resources Manager") sends BIS(RQE1) or BIS(RQE3) to the time 
that RM sends DEACTIVATE_SESSION or receives SESSION_DEACTIVATED. 


5. ACTIVE_*_COUNT counts active sessions. These counts are maintained by RM 
("Chapter 3. LU Resources Manager''). A session is active from the time that 
RM receives SESSION_ACTIVATED or +ACTIVATE_SESSION_RSP to the time that RM 
sends DEACTIVATE_SESSION or receives SESSION DEACTIVATED. ACTIVE_% COUNT 
‘includes sessions that are pending termination (see below). 
ACTIVE_SESSION_COUNT is the sum of ACTIVE_CONWINNERS_COUNT and 
ACTIVE _CONLOSERS_COUNT. 


6. PENDING_* COUNT counts pending-active sessions. These counts are maintained 
by RM ("Chapter 3. LU Resources Manager"). A session 1s pending active from 
the time that RM sends ACTIVATE_SESSION to the time that RM receives ACTI- 
VATE_SESSION_RSP. PENDING _SESSION_COUNT is the sum of PEND- 
ING_CONWINNERS COUNT and PENDING_CONLOSERS_COUNT. 


7. The SESSION_DEACTIVATED_TP is started when an UNBIND is sent or received. The 
related half-session and any PS that was using the session may still be active 
when the SESSION_DEACTIVATED_TP actually runs. The SESSION_DEACTIVATED_TP 
must take this into account. 


8. The range of possible maximum RU sizes is delimited at the high end by the 
values that can be encoded in BIND byte 9 or 10. At the low end; the archi- 
tectural limit is determined by the BIND encoding, but the implementation lim- 
it is determined by the requirement that an FM header fit entirely in one RU. 
This is to avoid deadlock complications that could occur if an incomplete 
FMH-5 arrives at the half-session because it is sent spanning more’ than one 
RU. 
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MODE 


NAME: mode name (see Note 3) 

SESSION_LIMIT: maximum number of sessions allowed for this partner (LU, mode) pair 

MIN_CONWINNERS_LIMIT: minimum number of contention winner sessions 

MIN_CONLOSERS_ LIMIT: minimum number of contention loser sessions 

CNOS_NEGOTIATION_IN_PROGRESS: possible values: TRUE» FALSE 
LIMIT_BEING_NEGOTIATED: when CNOS negotiation is in progress, the tentative new 
session limit | 


ACTIVE_SESSION_COUNT: (see Note 5) 
ACTIVE _CONWINNERS_COUNT: 
ACTIVE_CONLOSERS_COUNT: 


PENDING _SESSION_COUNT: (see Note 6) 
PENDING _CONWINNERS_COUNT : 
PENDING _CONLOSERS_COUNT : 


DRAIN_SELF: possible values: YES, NO 
DRAIN_PARTNER: possible values: YES», NO 
AUTO_ACTIVATIONS_LIMIT: 


Data Unique to Resources Manager 


TERMINATION_COUNT: (see Note 4) 

PENDING_TERMINATION_CONWINNERS: 

PENDING_TERMINATION_CONLOSERS: 

SINGLE_SESSION_POLARITY: possible values: FIRST_SPEAKER, BIDDER 
LOCAL_MAX_SESSION_LIMIT: maximum MODE session limit value 
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TRANSACTION_PROGRAM 


TRANSACTION_PROGRAM 


Each LUCB contains a TRANSACTION_PROGRAM_LIST. This list contains one entry for each 
transaction program Known at the local LU. Each TRANSACTION_PROGRAM entry in the TRANS- 
ACTION_PROGRAM_LIST contains information describing one transaction program. 


The TRANSACTION _PROGRAM_LIST is created at system-definition time . The initial values of 
the fields in each TRANSACTION_PROGRAM entry are implementation-defined. 


NOTE : See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for a list 
of valid symbol-string types for the Transaction program name. 


TRANSACTION_PROGRAM 


Shared Data 


TRANSACTION_PROGRAM_NAME: (up to 64 bytes long) 

PRIVILEGED_FUNCTIONS LIST: possible values: ATTACH_SERVICE_TP, CHANGE_NUMBER_OF_SESSIONS, 
DEFINE _LU_PARAMETERS, DISPLAY_LU_ PARAMETERS, SESSION_CONTROL 

RESOURCES SUPPORTED_LIST: possible values: BASIC_CONVERSATION, MAPPED_CONVERSATION 

VERIFY_PIP: possible values: YES, NO 

NUMBER_OF_PIP_SUBFIELDS: number of PIP subfields required by the TP 


Data Unique to RM 


SYNC_LEVELS SUPPORTED_LIST: possible values: NONE, CONFIRM, SYNCPT 
INSTANCE_LIMIT: maximum number of TPs that can be brought up (1 is the minimum) 
INSTANCE_COUNT: current number of TPs executing (initialized to 0) 

STATUS: possible values: ENABLED, DISABLED_TEMPORARY, DISABLED_PERMANENT 
WAITING INITIATION RQ_LIST: possible values: ATTACH_RECEIVED, START_TP 


Data Unique to PS.MC 


MC_FUNCTIONS SUPPORTED_LIST: possible values: MAPPING, FMH_DATA 
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RCB 


The RCB_LIST contains information about resources. There is one RCB_LIST per local LU and 
one RCB per resource known by that LU. The RCB_LIST is managed by RM ("Chapter 3. LU 
Resources Manager"). Entries are added to, and deleted from, the RCB_LIST by the 
resources manager. The RCB_LIST is also referenced by presentation services, e.g.> 
PS.CONV ("Chapter 5.1. Presentation Services--Conversation Verbs"). The RCB_LIST contains 
entries for all the resources associated with all the transaction program instances active 
at a particular LU. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-def ined. : 


LU names consist of type-G symbol strings. Mode names consist of type-A symbo 
strings. See SNA Formats for symbol string definitions. 


When the resources manager receives a GET_SESSION (page A-16) from PS.CONV and 
determines that only a bidder  half-session is available (i.e., all 
first-speaker half-sessions are in use), it has to request permission to use 
the half-session. Because permission may be denied, SESSION_PARMS PTR points 
to the GET_SESSION record while the request for permission to use the session 
is outstanding. If permission is denied, the GET_SESSION record is used to 
issue a new request for a session. After permission has been granted, or if a 
first-speaker session can be allocated, SESSION_PARMS PTR has a value of NULL. 


Used to purge Attaches from the TRANSACTION_PROGRAM.WAITING_INITIATION_RQ LIST 
when HS terminates. 


RCB 


: eo 
Shared Data | 


RCB_ID: ID of this RCB 

TCB_ID: ID of the transaction that owns this RCB 

HS_ID: ID of the half-session associated with this RCB 
SESSION_IDENTIFIER: session ID assigned to the conversation 
LU_NAME: partner LU name (see Notes 1 and 2) 

MODE_NAME: (see Note 2) 

CONVERSATION_CORRELATOR: (see Note 2) 


BRACKET_ID: unique value generated by RM to identify all records for a rr 
given conversation. ( 
SYNC_LEVEL: possible values: NONE, CONFIRM, SYNCPT Ne i 


SECURITY_SELECT: possible values: NONE, SAME, PGM 


Data Unique to RM 


SESSION_PARMS PTR: (see Note 3) 
TP_NAME: TP name sent on ALLOCATE or received on Attach (see Note 4) 
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e Data Unique to PS.CONV 


CONVERSATION_TYPE: possible values: BASIC_CONVERSATION, MAPPED_CONVERSATION 
LIMITED_BUFFER_POOL_ID: buffer pool ID 
PERMANENT_BUFFER_POOL_ID: buffer pool ID 
POST_CONDITIONS: 

FILL: possible values: BUFFER, LL 

MAX_LENGTH: maximum number of bytes in incoming logical record or buffer 
LOCKS: possible values: SHORT, LONG 
SEND_RU_SIZE: maximum number of bytes for outgoing MU record 
RQ_TO_SEND_RCVD: possible values: YES; NO 
HS_TO_PS_BUFFER_LIST: list of MU data structures (see page A-29) 


Data Unique to PS.MC 


MC_RECEIVE BUFFER: contains RECEIVED_INFO (see page A-7) 
.  MAPPER_SAVE_AREA: contains information used in mapping 
4 MC_MAX_SEND_SIZE: maximum number of bytes in a mapped-conversation logical record 
| MC_RQ_TO_SEND_RCVD: possible values: YES», NO 


RECEIVED_INFO 


RECEIVED_INFO is the structure that is inserted into the MC_RECEIVE_BUFFER_LIST. The 


a MC_RECEIVE_BUFFER_LIST is contained within an RCB_ and consists of information received by 
re PS.MC ("Chapter 5.2. Presentation Services--Mapped Conversation Verbs") but not yet passed 
to the transaction program. 


RECEIVED_INFO 
TYPE: possible values: MAP_NAME, MAP_NAME_AND_DATA_CONTINUED, 
DATA_CONTINUED, MAPPED_DATA, INDICATOR, RC 


eat, 
ae ~ 
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SCB 


There is one SCB per half-session. SCBs are maintained by the resources manager. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 


junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-defined. 


LU names consist of type-G symbol strings. Network-qualified LU names and 
mode names consist of type-A symbol strings. See SNA Formats’ for 
symbol-string definitions. 


SCB 


Data Unique to RM 


HS ID: unique SCB identifier 
SESSION_IDENTIFIER: ID used to identify session in BIND 
LU_NAME: partner LU name (see Notes) 
MODE_NAME: mode name (see Note 2) 
RCB_ID: ID of RCB representing the conversation that is using this session; null 
if no conversation is using this session 
FIRST_SPEAKER: possible values: YES, NO 
SEND_RU_SIZE: maximum number of bytes for an outgoing MU record 
LIMITED_BUFFER_POOL_ID: buffer pool ID 
PERMANENT_BUFFER_POOL_ID: buffer pool ID 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 
RTR_OWED: possible values: TRUE, FALSE @ 


fos 


> 


FULLY_QUALIFIED_LU_NAME: partner network-qualified LU name (see Note 2) 
RANDOM_DATA: used to validate FMH-12 


ia 
{ 
\ 
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C | TCB 


The TCB_LIST contains information about active transaction program instances. There is 
one TCB_LIST per local LU and one TCB per active transaction program instance running at 
that LU. The TCB_LIST is managed by RM ("Chapter 3. LU Resources Manager"). Entries are 
added to and deleted from the TCB_LIST by the resources manager. The TCB_LIST is also 
referenced by presentation services, e.g.» PS.CONV ("Chapter 5.1. Presentation Serv- 
ices--Conversation Verbs"). 


Each TCB contains an embedded RESOURCES LIST, which contains one (pointer) entry for each 


resource associated with a particular transaction program instance. 


NOTES: 1. See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for a list 
of valid symbol-string ices for the Transaction program name and Access Secu- 
rity Information. : 


Each entry in the RESOURCES LIST has a corresponding entry in the RCB_LIST. 
The RCB_LIST contains entries for all the resources associated with all the 
transaction program instances running at the LU. In contrast, the 
RESOURCES LIST contains entries for only those resources associated with a 
particular transaction program instance. 


ae 
} 


TCB 


Shared Data used by RM and PS. Initialized by RM. 


TCB_ID: identifies the PS process 
TRANSACTION_PROGRAM_NAME: (see Note 1) 
OWN_LU_ID: | 
LUW_IDENTIFIER 
ae, FULLY_QUALIFIED_LU_NAME: 
C) LUW_INSTANCE : 
e LUW_SEQUENCE_NUMBER: 
RESOURCES LIST: (see Note 2) 
CONTROLLING_COMPONENT: possible values: TP, SERVICE_COMPONENT 
INITIATING_SECURITY: initiating security information is received on the Attach 
that started this TP (see Note 1) 
PROFILE: 
USERID: 


ABORT_HS 


ABORT_HS indicates to the session manager that the half-session has found a severe error 
and cannot continue processing. This will cause an UNBIND to be sent for the aborted 
half-session. 


ABORT_HS 
HS ID: identifies the half-session sending this record 
SENSE_CODE: indicates the reason the half-session aborted 
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INIT_HS_RSP 


This record is a response to the INIT_HS record that was sent from the session manager to 


the half-session to initialize the half-session. The response indicates whether or not 
the initialization was successful (POS) or not (NEG). When NEG, the reason is indicated 
by the sense data in SENSE_CODE. 


INIT_HS_RSP 
TYPE: possible values: POS, NEG 
SENSE_CODE: indicating the type of error (reserved when TYPE=POS) 
HS_ID: identifies the half-session sending the record 


CONFIRMED 


CONFIRMED is sent by the half-session to PS_CONV to inform PS CONV that a positive 


response to the previous request for confirmation has been received. 


CONFIRMED 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 


RECEIVE_ERROR 


RECEIVE_ERROR is sent by the half-session to PS_CONV to inform PS_CONV that a -RSP( 0846) 
has been received. 


RECEIVE_ERROR 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 


REQUEST_TO_SEND 


REQUEST_TO_SEND is sent by the half-session to PS_CONV to inform PS_CONV that the trans- 


action program at the partner LU has requested to enter the send state for the conversa- 
tion. 


REQUEST_TO_SEND | 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 
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RSP_TO_REQUEST_TO_SEND 


RSP_TO_REQUEST_TO_SEND is sent by the half-session to PS_CONV to inform PS_CONV that the 
response to the previous MU (with PS_TO_HS.PS_TO_HS_VARIANT=REQUEST_TO_SEND -- page A-29 ) 
has been received. 


RSP_TO_REQUEST_TO_SEND 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 


BID 


BID is sent by the half-session to the resources manager to inform the resources manager 


that the partner LU has requested permission to use the half-session for a conversation. 
The resources manager replies with a BID_RSP record (page A-11). The half-session sends a 
BID record to the resources manager even if the partner LU is the first-speaker. 


BID 
CO HS ID: identifies the half-session sending this record 
J 


BID_RSP 


BID_RSP is sent by the half-session to the resources manager to inform the resources man- 
ager of the partner LU's response to the local LU's request to use the session (see 


aa BID_WITHOUT_ATTACH [page A-17]}. BID_RSP is sent by the half-session only if the local LU 
( is the bidder. If RTI = NEG, SENSE_CODE contains the sense data carried on the negative 
So response. 


BID_RSP is also sent by the resources manager to the half-session in response to a previ- 
ous BID record (page A-11) from the half-session. If RTI = POS, the partner LU is granted 
permission to use the session. If RTI = NEG, permission is denied and SENSE_CODE contains 
the sense data to be sent on the negative response. 


BID_RSP 
HS_ID: identifies the half-session sending this record 
RTI: type of response—possible values: POS, NEG 
SENSE_CODE: indicates the type of error (reserved when RTI=POS) 
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BIS_RQ 


BIS_RQ is sent by the half-session to the resources manager to inform the resources manag- 


er that a BIS(RQE1) request unit was received. 


BIS RQ is also sent by the resources manager to the half-session to request the half ses- 
sion to send a BIS(RQE1) request unit. 


BIS RQ 
HS ID: identifies the half-session sending this record 


BIS_REPLY 


BIS REPLY is sent by the half-session to the resources manager to inform the resources 
manager that a BIS(RQE3) request unit was received. 


BIS REPLY is also sent by the resources manager to the half-session to request the 
half-session to send a BIS(RQE3) request unit. 


BIS REPLY 
HS_ID: identifies the half-session sending this record 


FREE_SESSION 


FREE_SESSION is sent by the half-session to the resources manager to inform the resources 


manager that the half-session has become free (1.e., not in use by a conversation). 


FREE_SESSION 
HS_ID: identifies the half-session sending this record (the half-session that 
has become free) 


RTR_RQ 


RTR_RQ is sent by the half-session to the resources manager to inform the resources manag- 
er that an RTR request unit was received. # 


RTR_RQ is also sent by the resources manager to the half-session to request’ the 
half-session to send an RTR request unit. 


RTR_RQ 
HS ID: identifies the half-session sending this record 
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RTR_RSP 


RTR_RSP is sent by the half-session to the resources manager to inform the resources man- 
ager that an RTR response unit was received. If RTI = NEG, SENSE_CODE contains the sense 


data carried on the negative response. 


RTR_RSP is also sent by the resources manager to the half-session to request the 
half-session to send an RTR response unit. If RTI = NEG, SENSE_CODE contains the sense 
data to be sent with the negative response. 


RTR_RSP 
HS_ID: identifies the half-session sending this record 
RTI type of response: possible values: POS, NEG 
SENSE_CODE: indicates the type of error (reserved when RTI=POS) 


INIT_HS 


This record contains the information necessary for the half-session to initialize itself. 
It is sent when a successful session activation occurs and contains information from the 
BIND RU. 


Rd INIT_HS 


PATH_CONTROL_ID: identifies the path control the half-session communicates with 
TYPE of half-session: possible values: PRI, SEC 
DYNAMIC_BUFFER_POOL_ID: buffer pool ID 
LIMITED BUFFER POOL ID: buffer pool ID 
LSFID: see page A-28 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
SHORT_BIND_IMAGE: the first 26 bytes of the negotiated BIND image 
(see BIND in SNA Formats) 


c™ 


ACTIVATE_SESSION_RSP 


ACTIVATE_SESSION_RSP is sent by the session manager to the resources manager in reply to 
an ACTIVATE_SESSION record (page A-20). ACTIVATE_SESSION_RSP records need not be sent in 


the same order as the ACTIVATE_SESSION records, so CORRELATOR is used to correlate the 
ACTIVATE_SESSION_RSP to the ACTIVATE_SESSION. If TYPE = POS (a session was activated), 
SESSION_INFORMATION specifies session characteristics. If TYPE = NEG (a _ session was not 
activated), ERROR_TYPE contains a retry/no-retry indication. 


ACTIVATE_SESSION_RSP : 
CORRELATOR: as supplied in ACTIVATE_SESSION (see page A-20) 
TYPE of response: possible values: POS, NEG 
- SESSION_INFORMATION: (reserved when TYPE=NEG--see page A-32) 
C ERROR_TYPE: possible values: RETRY, NO_RETRY (reserved when TYPE=PO0S) 
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SESSION_ACTIVATED 


SESSION_ACTIVATED is sent by the session manager to the resources manager to notify the 
resources manager that the partner LU named by LU_NAME and MODE_NAME has activated a ses- 
sion to this LU. The characteristics of the session are specified in SESSION_INFORMATION. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 


junction with MODE_NAME when requesting the allocation of a conversation. It 
is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 


implementation-def ined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See SNA Formats for symbol-string definitions. 


SESSION_ACTIVATED 
SESSION_INFORMATION: (see page A-32) 
LU_NAME: (see Notes 1 and 2) 
MODE_NAME: (see Note 2) 


SESSION_DEACTIVATED 


SESSION_DEACTIVATED is sent by the session manager to the resources manager to notify the 
resources manager that the session identified by HS_ID has been deactivated. It is also 


used internally in the resources manager. 


SESSION_DEACTIVATED 
HS ID: identifies the half-session that was deactivated 
REASON for deactivation: possible values: NORMAL, ABNORMAL_RETRY, ABNORMAL_NO_RETRY 
SENSE_CODE: provides additional information on 
session deactivation (reserved when REASON = NORMAL). 


SEND_ERROR 


SEND_ERROR is sent by PS_CONV to the half-session to request the half-session to send a 
-RSP( 0846 ). | 


( 


Pian 
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SEND_ERROR 
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ALLOCATE_RCB 


ALLOCATE_RCB is sent by PS.CONV to the resources manager to request creation and initial- 
ization of a resource control block. The resources manager also attempts to reserve a 
first-speaker session if IMMEDIATE_SESSION = YES. The resources manager replies to the 
ALLOCATE_RCB with an RCB_ALLOCATED record (page A-21). 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-defined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See SNA Formats for symbol-string definitions. 


ALLOCATE_RCB 
TCB_ID: ID of PS process that sent ALLOCATE_RCB 
LU_NAME: (see Notes 1 and 2) 
MODE_NAME: (see Note 2) 
IMMEDIATE_SESSION: possible values: YES, NO 
SYNC_LEVEL: possible values: NONE, CONFIRM, SYNCPT 
SECURITY_SELECT: possible values: NONE, SAME, PGM 


CHANGE_SESSIONS 


CHANGE_SESSIONS is sent by PS.COPR to the resources manager to inform the resources manag- 
er of a change in the session limits for (LU_NAME, MODE_NAME). PS.COPR changes the ses- 
sion limits in the MODE control block (page A-3) before sending this record to the 
resources manager. RESPONSIBLE = YES if this LU is responsible for deactivating sessions 
to satisfy the new session limits. DELTA contains the (signed) difference between the 
current MODE.SESSION_LIMIT and the previous MODE.SESSION_LIMIT. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It 1s a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-def ined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See SNA Formats for symbol string definitions. 


CHANGE_SESSIONS 
TCB_ID: ID of the PS process that sent CHANGE_SESSIONS 
RESPONSIBLE: possible values: YES, NO 
LU_NAME: (see Notes 1 and 2) 
MODE_NAME: (see Note 2) 
DELTA: change in MODE.SESSION_LIMIT 
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DEALLOCATE_RCB 


DEALLOCATE_RCB is sent by PS.CONV to the resources manager to request destruction of the 


resource control block identified by RCB_ID. The resources manager replies to the DEALLO- 
CATE_RCB with an RCB_DEALLOCATED record (page A-21). 


DEALLOCATE_RCB 
TCB_ID: ID of the PS process that sent DEALLOCATE_RCB 
RCB_ID: ID of the RCB to deallocate 


GET_SESSION 


GET_SESSION is sent by PS.CONV to the resources manager to request the allocation of a 
session to the conversation identified by RCB_ID. The resources manager replies to the 
GET_SESSION with a SESSION_ALLOCATED record (page A-22). 


GET_SESSION 
TCB_ID: ID of the PS process that sent GET_SESSION 
RCB_ID: ID of the conversation 


RM_ACTIVATE_SESSION 


RM_ACTIVATE_SESSION is sent by PS.COPR to the resources manager to request activation of a 
new session with the partner LU identified by LU_NAME on the mode name identified by 
MODE_NAME. This record is sent as a result of the ACTIVATE_SESSION control operator verb. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-def ined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See SNA Formats for symbol-string definitions. 


RM_ACTIVATE_SESSION 
TCB_ID: ID of the PS process that sent RM_ACTIVATE_SESSION 
LU_NAME: (see Notes 1 and 2) 
MODE_NAME: (see Note 2) 
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C | RM_DEACTIVATE_SESSION 
oF 


RM_DEACTIVATE_SESSION is sent by PS.COPR to the resources manager to request deactivation 


of the session identified by SESSION_ID. This record is sent as a_ result of the DEACTI- 
VATE_SESSION control-operator verb. 


RM_DEACTIVATE_SESSION 
TCB_ID: ID of the PS process that sent RM_DEACTIVATE_SESSION 
SESSION_ID: identifies the session | 
TYPE: possible values: NORMAL, CLEANUP 


C TERMINATE_PS 


TERMINATE_PS is sent by PS_INITIALIZE to the resources manager to request termination of 
the process that comprises presentation services and the transaction program. 


TERMINATE_PS 
TCB_ID: ID of the PS process to be terminated 


UNBIND_PROTOCOL_ERROR 


UNBIND_PROTOCOL_ERROR is sent by PS_CONV or PS_INITIALIZE to the resources manager to 


request abnormal termination of the session identified by HS_ID. The record is sent when 
the partner LU commits a_ serious protocol error. The sense data to be carried on the 
UNBIND is in SENSE_CODE. 


UNBIND_PROTOCOL_ERROR 


= TCB_ID: ID of the PS process that sent UNBIND_PROTOCOL_ERROR 
: HS_ID: ID of the half-session to be deactivated 
“ SENSE_CODE: 


BID_WITHOUT_ATTACH 


BID_WITHOUT_ATTACH is sent by the resources manager to the half-session to request permis- 
sion (from the partner LU) to use the session. The request for permission is not accompa- 
nied by any other data. The resources manager sends BID_WITHOUT_ATTACH only if this LU is 
the bidder, since it does not need permission from the partner LU to use a first-speaker 
session. The half-session informs the resources manager of the partner LU's response with 
a BID_RSP record (page A-11). 


C BID_WITHOUT_ATTACH 
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| 
f 


BRACKET_FREED 


BRACKET_FREED is sent by the resources manager to the half-session to inform the 
half-session that it may purge records from PS with a matching BRACKET_ID. This signal is 
sent after PS has sent DEALLOCATE_RCB for the bracket. 


BRACKET_FREED | : 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 


ENCIPHERED_RD2Z 


ENCIPHERED_RD2 is sent by RM to the half-session to request the half-session to send an 
FMH-12. 


ENCIPHERED_RD2 
SEND_PARM: (see page A-32) 


HS_PS_CONNECTED 


HS_PS_ CONNECTED is sent by the resources manager to the half-session to inform the 
half-session that it has been connected to a presentation services process. This occurs 
as a result of the allocation of a session to a conversation. 


yo 
HS_PS_CONNECTED 
PS_ID: ID of a presentation services process \ 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 


SS ener 


RM_HS_ CONNECTED 


RM_HS_CONNECTED is sent by the resources manager to the half-session to inform the 
half-session that it may forward incoming data (e.g., FMH-5s) to RM. This occurs after 
the session manager has informed RM that HS has been successfully initialized. 


RM_HS_CONNECTED | (~ 
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YIELD_SESSION 


YIELD SESSION is sent by the resources manager to the half-session to end the open bracket 
in a newly activated session. When a session is activated, the session comes up in the 


"“in-bracket" state, with the primary LU in control. If the resources manager at the pri- 
mary LU does not have a waiting session-allocation request (see GET_SESSION, page A-16 ), 
it sends YIELD_SESSION to the half-session; the half-session then reverts to contention 
state. 


YIELD SESSION 


START_TP 


START_TP is sent from a local node component to the resources manager to request initi- 
ation of a transaction program. It is also sent from the resources manager to presenta- 
tion services during the initiation processing. 


NOTES: 1. The local LU name is the name by which the receiver of the START_TP Knows the 
originator of the START_TP. This field is used for security "come-from" 
checking of START_TP records. If come-from checking is not required by the 
target transaction program, this field is not referenced by the receiver. 


The network-qualified LU name is specified by the issuer of START_TP. The 
name specified uniquely identifies an LU. If the receiver of the START_TP has 
a network-qualified LU name, the name specified is always network-qualified. 
‘This LU name is used to generate logical-unit-of-work identifiers (LUW IDs). 
The non-LU 6.2 request originator never generates its own LUW IDs. The LUW ID 
is used for sync point conversations, network problem determination, and net- 
work accounting functions. Node component procedures that are able to send 
START_TP records to RM are considered privileged, protected processes with 
content security (1.e.; integrity). These procedures may supply the 
network-qualified LU name of the requester or an Already-Verified indication 
for security (1i.e., a user ID indicated as already verified, thus eliminating 
the need for a password). 


START_TP 


REPLY: possible values: YES, NO 
TARGET_TP_NAME: name of the TP to be started 
SECURITY_SELECT: possible values: NONE, PGM, ALREADY_VERIFIED 
SECURITY (reserved when SECURITY_SELECT=NONE ) 
PROFILE: 
PASSWORD: 
USER_ID: | 
TCB_ID: transaction program instance identifier 
PIP_LIST: list of PIP_DATA 
FULLY_QUALIFIED_LU_NAME: initiator network-qualified LU name 
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START_TP_REPLY 


START_TP_REPLY is sent by the resources manager to the local node component that sent the 


START_TP record. 


START_TP_REPLY ; 
RESPONSE_CODE: possible values: OK, PIP_NOT_ALLOWED, PIP_NOT_SPECIFIED_CORRECTLY, 
TPN_NOT_RECOGNIZED, TRANS_PGM_NOT_AVAILABLE_RETRY, INVALID_FULLY_QUALIFIED_LU_NAME, 
PS CREATION_FAILURE, TRANS_PGM_NOT_AVAIL_NO_RETRY, SECURITY_NOT_VALID 
TCB_ID: transaction program instance identifier 


SEND_RTR 


SEND_RTR is sent to the resources manager to prompt the resources manager to send an RTR 
request on the session specified by HS_ID. 


SEND_RTR 


ACTIVATE_SESSION 


ACTIVATE_SESSION is sent by the resources manager to the session manager to request the 
activation of a session of type SESSION_TYPE with the partner LU identified by LU_NAME and 
mode name identified by MODE_NAME. Session manager replies to ACTIVATE_SESSION with an 
ACTIVATE_SESSION_RSP record (page A-13) that has the same CORRELATOR value as that in the 
ACTIVATE_SESSION. 


NOTES: 1. The (partner) LU_NAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one local LU Knows another (partner) LU and is not 
sent outside the local LU. The maximum length of the  LU_NAME is 
implementation-defined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See SNA Formats for symbol-string definitions. 


ACTIVATE_SESSION 
CORRELATOR: 
SESSION_TYPE: possible values: FIRST_SPEAKER, BIDDER 
LU_NAME: (see Notes 1 and 2) 
MODE_NAME: (see Note 2) 
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DEACTIVATE_SESSION 


Se DEACTIVATE_SESSION 


DEACTIVATE_SESSION is sent by the resources manager to session manager to request the 


deactivation of a session. If STATUS = ACTIVE, the session is identified by HS_ID. If 
STATUS = PENDING, the session is identified by CORRELATOR», which contains the same value 
used in the ACTIVATE_SESSION request. 


DEACTIVATE_SESSION 
STATUS: possible values: ACTIVE, PENDING 
CORRELATOR: (reserved when STATUS=ACTIVE } 
HS_ID: (reserved when STATUS = PENDING) 
TYPE of deactivation: possible values: NORMAL, CLEANUP, ABNORMAL 
(CLEANUP or ABNORMAL imply STATUS=ACTIVE ) 
SENSE_CODE: reason for deactivation 


CONVERSATION_FAILURE 


CONVERSATION_FAILURE is sent by the resources manager to PS_CONV to notify presentation 
services of the failure of the conversation identified by RCB_ID. 


CONVERSATION_FATLURE 
s RCB_ID: ID of failed conversation 
oe REASON: possible values: SON, PROTOCOL_VIOLATION 


RCB_ALLOCATED 


RCB_ALLOCATED is sent by the resources manager to PS_CONV in reply to an ALLOCATE_RCB 
(page A-15). RETURN_CODE indicates the success of the allocation. If RETURN_CODE = OK, 
RCB_ID contains the ID of the newly created resource control block. 


RCB_ALLOCATED 
RETURN_CODE: possible values: OK, UNSUCCESSFUL, SYNC_LEVEL_NOT_SUPPORTED 
RCB_ID: ID of newly created resource control block (reserved when RETURN_CODE*OK ) 
SEND_RU_SIZE: maximum size of an RU on this session 
LIMITED _BUFFER_POOL_ID: buffer pool ID 
PERMANENT_BUFFER_POOL_ID: buffer pool ID 


RCB_DEALLOCATED 


_ RCB_DEALLOCATED is sent by the resources manager to PS_CONV in reply to a DEALLOCATE_RCB 
C record (page A-16). 


RCB_DEALLOCATED ; 
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RM_SESSION_ACTIVATED 


RM_SESSION_ACTIVATED is sent by the resources manager to PS_COPR in reply to an 


RM_ACTIVATE_SESSION record (page A-16). The success or failure of the session activation 
1s indicated in the RETURN_CODE field. 


RM_SESSION_ACTIVATED 
RETURN_CODE: possible values: OK, ACTIVATION_FAILURE_NO_RETRY, 
ACTIVATION_FAILURE_RETRY», LU_MODE_SESSION_LIMIT_EXCEEDED 


SESSION_ALLOCATED 


SESSION_ALLOCATED is sent by the resources manager to PS_CONV in reply to a GET_SESSION 
record (page A-16). RETURN_CODE indicates the success or failure of the session allo- 
cation. 


SESSION_ALLOCATED 
SEND_RU_SIZE: maximum size or an RU on this session 
LIMITED BUFFER _POOL_ID: buffer pool ID 
PERMANENT_BUFFER_POOL_ID: buffer pool ID 
IN_CONVERSATION: possible values: YES, NO 
RETURN_CODE: possible values: OK, UNSUCCESSFUL_RETRY, UNSUCCESSFUL_NO_RETRY, 
SYNC_LEVEL_NOT_SUPPORTED 


ASSIGN_PCID 


SM sends this message to SS to request the assignment of a FQPCID. The FQPCID that is 
assigned is returned in an ASSIGN_PCID_RSP message. 


If the DUPLICATE_PCID field in the ASSIGN _PCID message has a value of YES, it indicates 
that the last FQPCID assigned by SS to the requesting SM had the same value as another 
FQPCID already being used by that SM. This can occur when two nodes’ in the network have 
the same CP names. : 


ASSIGN_PCID 
SM_PROCESS_ID: requesting SM process ID 
DUPLICATE_PCID: possible values: YES, NO 
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ASSIGN_PCID_RSP 


SS returns this message in response to an ASSIGN_PCID message» received from SM. 
tains the FQPCID that is assigned. 


ASSIGN_PCID_RSP . 
FQPCID: fully qualified procedure correlator identifier 


INIT_SIGNAL_NEG_RSP 


SS sends this message in response to an INIT_SIGNAL message received from SM. 
when the session initiation request in the INIT_SIGNAL message cannot be satisfied. 


INIT_SIGNAL_NEG_RSP 
FQPCID: fully qualified procedure correlator identifier 


CINIT_SIGNAL 


SS sends this message in response to an INIT_SIGNAL message received from SM. 
the information that SM needs to build and send a BIND. 


CINIT_SIGNAL 
FQPCID: fully qualified procedure correlator identifier 
PATH_CONTROL_ID: session path control ID 
PC_CHARACTERISTICS: see page A-32 
COS_TPF_PRESENT: possible values: YES, NO 
COS TPF: see SNA Formats for format 


INIT_SIGNAL 


ASSIGN_PCID_RSP 


It con- 


It is sent 


It contains 


SM sends this message to SS in order to obtain the information necessary to build and send 


a BIND. 
response. 


INIT_SIGNAL 
SM_PROCESS_ ID: requesting SM process identifier 
FQPCID: fully qualified procedure correlator identifier 
SLU_NAME: secondary LU name 
PLU_NAME: primary LU name 
MODE_NAME: mode name 


Appendix A. 


SS sends either an INIT_SIGNAL_NEG_RSP message or a CINIT_SIGNAL message 


Node Data Structures 


in 


A-23 


SESSST_SIGNAL 


SESSST_SIGNAL 


SM sends this message to SS whenever it successfully processes a received BIND. 


SESSST_SIGNAL 
PATH_CONTROL_ID: path control identifier 


SESSEND_SIGNAL 


SESSEND_SIGNAL 


The SENSE_CODE field has a nonzero value only when the session terminated abnormally. 


SM sends this message to SS whenever a session is terminated. 


SENSE_CODE: nonzero when session terminated abnormally 
FQPCID: fully qualified procedure correlator identifier 


PATH_CONTROL_ID: path control identifier 


PC_HS_DISCONNECT 


PC_HS_ DISCONNECT instructs path control to detach the half-session. 


PC_HS_DISCONNECT 
PATH_CONTROL_ID: path control identifier 
LFSID: see page A-28 


SESSION_ROUTE_INOP 


SESSION_ROUTE_INOP informs all the SMs that a particular route (identified by 


PATH_CONTROL_ID) is lost and that all sessions 
be taken down. 


(active and pending) using that route must 


SESSION_ROUTE_INOP 
PATH_CONTROL_ID: path control identifier 
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ABEND_NOTIFICATION 


ABEND_NOTIFICATION 
ABENDING_PROCESS: name of the abending process 
PROCESS ID: ID of the abending process 
REASON: cause of abend 


ASSIGN_LFSID 


ASSIGN_LFSID requests the procurement of a local LFSID from the specified address space. 
The LFSID 1s to be associated with the specified SM. The assigned LFSID is returned to SM 
in the ASSIGN_LFSID_RSP signal. 


ASSIGN_LFSID 
PATH_CONTROL_ID: path control identifier 
SM_PROCESS_ID: SM identity for the LFSID 
PROCESS_ID_TYPE: possible values: SM 
SENSE_CODE: 

LFSID: see page A-28 


FREE_LFSID 


FREE_LFSID requests that a previously assigned LFSID be freed (marked not in-use). No 
response is returned. 


FREE_LFSID 
PATH_CONTROL_ID: path control identifier 
LFSID: ID to be freed--see page A-28 


LFSID_IN_USE_RSP 


The LFSID_IN_USE_RSP signal resolves the question of whether or not another node has tried 
to use a LFSID already marked in-use by ASM. The LFSID_IN_USE signal has chased any work 


queued to the SM, and by the time ASM gets this LFSID_IN_USE_RSP, the question of dupli- 
cate LFSID usage has been correctly ascertained (any UNBIND processing that was in 
progress has been completed). 


LFSID_IN_USE_RSP 
PATH_CONTROL_ID: path contol identifier 
LFSID: see page A-28 
ANSWER: possible values: YES», NO 
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ASSIGN_LFSID_RSP 


ASSIGN_LFSID_RSP 


ASM sends this message in response to an ASSIGN_LFSID message, requesting the assignment 


of an LFSID to a particular SM. It contains the LFSID that was assigned. 


If the SENSE_CODE field has a nonzero value, it indicates that an LFSID was not assigned. 


ASSIGN_LFSID_RSP 
PATH_CONTROL_ID: path control identifier 
SM_PROCESS_ID: SM identity for the LFSID 
PROCESS_ID_TYPE: possible values: SM 
SENSE_CODE: 
LFSID: see page A-28 — 


> are 


LFSID_IN_USE 


The LFSID_IN_USE signal asks the SM if an LFSID is still in-use. A BIND was received with 


an LFSID that appears to be still in-use. However, the node on the other end of the Link 
may just be faster. This signal will chase any work queued to the SM, and by the time ASM 
gets the LFSID_IN_USE_RSP, the question of duplicate LFSID usage can be correctly ascer- 
tained. 


LFSID_IN_USE 
PATH_CONTROL_ID: path control identifier 
LFSID: see page A-28 . 
ANSWER: possible values: YES, NO 


HS_CREATE_PARMS 


This signal contains the data that HS requires to initialize itself. 


HS_CREATE_PARMS 
LU_ID: LU, RM, and SM process ID 
HS_ID: ID of the newly created half-session 
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| Es | PS _CREATE_PARMS 


This signal contains the data that PS requires to initialize itself. 


PS _CREATE_PARMS 
| | LUCB_LIST_PTR: pointer to the LUCB_LIST 
| LU_ID: ID of this PS's LU and RM process 
, TCB_LIST_PTR: pointer to the TCB_LIST 
TCB_ID: ID of this PS process 
RCB_LIST_PTR: pointer to the RCB_LIST 


Se RM_CREATE_PARMS 


This signal contains the data that RM requires to initialize itself. 


RM_CREATE_PARMS 
LUCB_LIST_PTR: pointer to the LUCB_LIST 
LU_ID: LU process ID 


SM_CREATE_PARMS 


This signal ‘contains the data that SM requires to initialize itself. 


SM_CREATE_PARMS 
LU_ID: LU process ID 
LUCB_LIST_PTR: pointer to the list of LUCBs 


RM_CREATED 
LU_ID: ID of the created RM 


| CRV_RQ_RU 


L CRV_RQ_RU | 
wi RQ_CODE: possible values: X'CO' (signifying CRV) 
CRYPTO_SEED: enciphered transform of test value from RSP( BIND) 
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LFSID 


Local-Form Session Identifier (LFSID) associated with a half-session. 


LFSID 
SESSION_ID: 
SIDH: high-order byte of session identifier 
SIDL: low-order byte of session identifier 
ODAI: 


A-28 SNA LU 6.2 Reference: Peer Protocols 


a 


A message unit (MU) is an interprocess signal that always contains a PIU (TH-RH-RU). The 
MU contains two types of PIUs: 


e session traffic: regular data flow 


e nonsession traffic: BIND, +tRSP(BIND), UNBIND, and +RSP(UNBIND) 


The MU contains a header that varies depending upon the type of PIU. 


MU 
HEADER_TYPE: possible values: BIND_RQ_SEND, BIND_RSP_SEND, UNBIND_RQ_SEND, 
UNBIND_RQ_RCV, UNBIND_RSP_SEND, BIND_RQ_RCV, BIND_RSP_RCV, HS_TO_RM, RM_TO_PS, 
HS_TO_PS, PS_TO_HS 


Header type BIND_RQ_SEND fields. 


a 


BIND_RQ_SEND 
LU_LID: LU identifier 
SENDER: 
ID: sending process ID 
TYPE: possible values: SM 
HS ID: half-session ID for the session 
TRANSMISSION PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
LFSID: see page A-28 
PATH_CONTROL_ID: path control identifier 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 


| : ; 
Header type BIND_RSP_SEND fields. 


BIND_RSP_SEND 
SENDER: 
ID: sending process ID 
TYPE: possible values: SM 
LFSID: see page A-28 
HS_ID: half-session ID for the session 
sass TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
/ PATH_CONTROL_ID: path control identifier 
od FREE_LFSID: 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 


Header type UNBIND_RQ_SEND fields. 


UNBIND_RQ_SEND 

SENDER: 

ID: sending process ID 

TYPE: possible values: SM 
LFSID: see page A-28 
HS_ID: 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
FREE_LFSID: possible values: YES, NO 
PATH_CONTROL_ID: path control identifier 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 
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Header type UNBIND_RQ_RCV fields. 


UNBIND_RQ_RCV 

SENDER: 

ID: sending process ID 

TYPE: possible values: SM 
LFSID: see page A-28 
HS_ID: 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
FREE_LFSID: possible values: YES, NO | 
PATH_CONTROL_ID: path control identifier 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 


Header type UNBIND_RSP_SEND fields. 


UNBIND_RSP_SEND 

LU_ID: 
SENDER: 

ID: sending process ID 

TYPE: possible values: SM 
HS_ID: half-session ID for the session 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
FREE_LFSID: possible values: YES, NO 
PATH_CONTROL_ID: path control identifier 
-PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 


Header type BIND_RQ RCV fields. 


BIND_RQ_RCV 

SENDER: 

ID: sending process ID 

TYPE: possible values: SM 
LFSID: see page A-28 
HS_ID: half-session ID for the session 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
FREE_LFSID: possible values: YES, NO 
PATH_CONTROL_ID: path control identifier 
PC_CHARACTERISTICS: see page A-32 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 


Header type BIND_RSP_RCV fields. 


BIND_RSP_RCV 
SENDER: 
ID: sending process ID 
TYPE: possible values: SM 
LFSID: see page A-28 
HS ID: half-session ID for the session 
TRANSMISSION_PRIORITY: possible values: LOW, MEDIUM, HIGH, NETWORK 
FREE_LFSID: possible values: YES, NO 
PATH_CONTROL_ID: path control identifier 
PARALLEL_SESSIONS: parallel session support indicator 
ADAPTIVE_PACING: adaptive pacing support indicator 
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Header type HS_TO_RM fields. 


HS_TO_RM 
HS ID: identifies the half-session that sent the record to RM 


Header type RM_TO_PS fields. 


RM_TO_PS 
HS_ID: half-session ID associated with the conversation 
TCB_ID: PS id 
RCB_ID: conversation ID 
SEND_RU_SIZE: maximum number of bytes for outgoing MU record 
LIMITED BUFFER_POOL_ID: buffer pool ID 
PERMANENT _BUFFER_POOL_ID: buffer pool ID 
RETURN_CODE: result of the RM checks of the Attach 


Header type HS_TO_PS fields. 


HS TO PS 
BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 
FMH: possible values: YES, NO 
TYPE: possible values: NOT_END_OF_DATA, CONFIRM, PREPARE_TO_RCV_CONFIRM; 
PREPARE_TO_RCV_FLUSH, DEALLOCATE_CONFIRM, DEALLOCATE_FLUSH 


Header type PS_TO_HS fields. 


PS _TO_HS 

BRACKET_ID: unique value generated by RM to identify all records for a 
given conversation. 

PS_TO_HS_VARIANT: possible values: CONFIRMED, REQUEST_TO_SEND, 
SEND_DATA_RECORD, SEND_ERROR 

ALLOCATE: possible values: YES», NO 

FMH: possible values: YES, NO 

TYPE: possible values: CONFIRM, DEALLOCATE_CONFIRM, DEALLOCATE_FLUSH, 
FLUSH, PREPARE_TO_RECEIVE_FLUSH, PREPARE_TO_RECEIVE_CONFIRM_SHORT, 
PREPARE_TO_RECEIVE_CONFIRM_LONG 


Fields present on all header types. 


TH: see SNA Formats for additional information 
BIU: basic information unit 
RH: see SNA Formats for additional information 


RU: data being sent or received 
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PC_CHARACTERISTICS 


PC_CHARACTERISTICS. 


Defines the characteristics of path control. 


PC_CHARACTERISTICS 
MAX_SEND_BTU_SIZE: maximum basic transmission unit send size 
MAX_RCV_BTU_SIZE: maximum basic transmission unit receive size 
ADJACENT_NODE_BIND_REASSEMBLY: possible values: SUPPORTED, NOT_SUPPORTED 


SEND_PARM 


SEND_PARM is a substructure that is embedded in ENCIPHERED_RD2 (page A-18). It contains 


the data to be sent to the half-session as well as an encoding of the RH bit-settings. If 
ALLOCATE = YES, this data 1s the first to be sent on a conversation. If FMH = YES, DATA 
begins with an FM header (FMH-5 or FMH-7). 


SEND_PARM 
ALLOCATE: possible values: YES, NO (1f ALLOCATE=YES, DATA is first in bracket) 


FMH: possible values: YES, NO (if FMH=YES, DATA begins with FM header ) 

TYPE: possible values: NOT_END_OF_DATA, FLUSH, CONFIRM, DEALLOCATE_CONFIRM, 
DEALLOCATE_FLUSH, PREPARE_TO_RCV_FLUSH, PREPARE_TO_RCV_CONFIRM_SHORT, 
PREPARE_TO_RCV_CONFIRM_LONG 

DATA: data to be sent on the session 


SESSION_INFORMATION 


SESSION_INFORMATION is’ a substructure that is embedded in SESSION_ACTIVATED (page A-14) 


and ACTIVATE_SESSION_RSP (page .A-13). Sent from the session manager to the resources man- 
ager, SESSION_INFORMATION contains data about the session that has just been activated. 


SESSION_INFORMATION 
HS_ID: half-session identifier 
HALF_SESSION_TYPE: possible values: PRI, SEC 
BRACKET_TYPE: possible values: FIRST_SPEAKER, BIDDER 
SEND_RU_SIZE: maximum send RU size for this session 
LIMITED_BUFFER_POOL_ID: buffer pool ID 
PERMANENT_BUFFER_POOL_ID: buffer pool ID 
SESSION_IDENTIFIER: unique (for this LU) 8-byte session identifier 
RANDOM_DATA: used to validate FMH-12 
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SNF 


SNF 


This data structure defines the Sequence Number field in the TH. 


SNF: a 16-bit sequence number field. 
SQN: a 16-bit sequence number whose value wraps to 0 after 65535. 
BRACKET_STARTED_BY: possible values are PRI (1) or SEE (0). 
The high-order bit of the sequence number field is set when the bracket is started 
by the primary half-session and reset when the bracket is started by the secondary 
half-session. This is done so that sequence numbers on BB requests are unique. 
NUMBER: a 15-bit sequence number whose value wraps to 0 after 32767. 
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---. APPENDIX B. BUFFER MANAGER 


INTRODUCTION 


TYPES OF 


Each node has a buffer manager (BM), which 
controls the buffers used for the storage of 


data that flows to and from the network. 
This appendix describes the buffer manager 
functions, services, and protocol boundary 


with LU components. (Other node components 
that interact with BM generally are not dis- 
cussed in this book. ) 


BM provides the following functions: 


1. Controls allocation and deallocation of 
storage used for buffers 


2. Limits allocation of buffers when avail- 
able storage runs low. 


3. Allows components to reserve storage in 
buffer pools to guarantee availability of 
enough buffers to complete distinct 
tasks. 


4. Allows processes to suspend processing 
pending availability of storage for buff- 
ers. 


Two pacing indicators are used by BM. 


1. Pacing indicator (PI): A pacing request 
1s a normal-flow request that has the PI 
bit (in the RH) set to PAC. When it is 

- set, it indicates that an RU is the first 
RU in the last window granted permission 
to be sent, and a new send window is 
requested. Otherwise, the PI bit is set 
to -PAC, indicating a new send window is 
not needed. 


BUFFERS 


BM provides five different types of buffers, 
four of which it organizes in buffer pools: 


¢ Demand buffers 

e Limited buffers 

e¢ = Permanent buffers 

® Fixed dynamic buffers 

e Varying dynamic buffers 


All except demand buffers are in pools. 


2. Request Larger Window indicator (RLWI): 
The RLWI field in the RH is used by the 
sending side to indicate to the receiving 
side that it would like to have a larger 
window (i.e., larger than the current 
window). The RLWI bit has meaning only 
in a pacing request and is reserved ina 
response. When the HS (send side) 
receives a solicited IPM, the send resi- 
dual pacing count gets updated (see Fig- 
ure B-4 on page B-16 and Figure B-5 on 
page B-17 as an example). If the send 
pacing queue has more requests to be sent 
(i1.e., more than the current send pacing 


window), the HS (send side) sends the 
next pacing request with RLWI set (to 
RLW) to request a larger window. Other- 


wise, the RLWI is set to -RLW, indicating 
a larger window is not needed. 


When a new pacing window is needed, HS sends 
a normal-flow request to its partner HS; this 
request is flagged with PAC (and RLW, if a 
larger window is requested). When this 
normal-flow request is received by HS, HS 
requests a buffer from a dynamic buffer pool 
to store this normal-flow request and later 
sends it to PS. HS (fon the receive side) 
passes the PI and RLWI values to BM when 
issuing the GET_BUFFER call, to inform BM 
that a new send window (and larger window, if 
RLW is set) has been requested by HS on the 
send side. (See Figure B-2 on page B-12; 
Figure B-3 on page B-13, and the GET_BUFFER 
call in this appendix for more details.) BM 
then replenishes the pool when the same buff- 
er is subsequently freed. 


A buffer pool is a set of buffers with the 
same characteristics (e.g.» size, use», owners 
pool identification). BM creates a buffer 
pool upon request from SM, but HS is desig- 
nated the owner of the buffer pool. After SM 
requests that BM create a buffer pool, LU 
components can get buffers from the created 
buffer pool, free buffers that they have 
removed from the buffer pool, adjust the size 
of the buffer pool, return (release) buffers 
to BM, and destroy a buffer pool or a speci- 
fied number (1 to all) of the buffers in a 
buffer pool. (Destroying a buffer means 
removing the buffer from the pool and making 
it unavailable to the LU components from that 
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pool. Destroying the buffer pool means mak- 
ing the pool itself no longer available to 
the LU components. ) 


For three of the four types of buffer pools 
(permanent, fixed dynamic, and varying dynam- 
ic), BM reserves buffers for the associated 
buffer pool when it creates the buffer pool. 
Creation of these three pools involves set- 
ting the size of each buffer in the pool (to 
some fixed value) and the number of buffers 
initially reserved for the pool in accordance 
with parameters in the CREATE_BUF_POOL used 
to create the pool, e.g., for adaptive pac- 
ing, 1 buffer, and, for fixed pacing, the 
number of buffers in the pacing window (nego- 
tiated during session initiation). 


BM allocates storage for demand and limited 
buffers individually at GET_BUFFER time. 


The following sections describe the different 
types of buffers and pools provided by BM. 


e DEMAND BUFFERS 


Demand buffers are not reserved ahead of 
time and are not associated with a pool. 
Demand buffers are requested when 
requests for other buffer cannot be met. 
For example, normally, HS requests a per- 
manent buffer to send expedited-flow 
requests (1.e., a CRV) and PS will 
request a permanent buffer to send 
normal-flow and expedited-flow responses. 
If no permanent buffer is available, they 
will request a demand buffer instead. 
When BM receives a request for a demand 
buffer and sufficient storage exists, BM 
allocates a demand buffer to the buffer 
requester. If the buffer is not avail- 
able, and the buffer requester is willing 
to wait (as specified on the GET_BUFFER 
call), BM queues the request (and the 
requesting process is suspended) until a 
demand buffer is available; otherwise, 
the request is rejected. 


e LIMITED BUFFER POOLS 


SM sets up a limited buffer pool for the 
session when i1%t 1s created. SM creates 
the pool, designating HS as its owner, 
and initializes its limit count to the 
number of buffers needed for the first 
send pacing window. Buffers "belonging" 
to a limited buffer pool are allocated on 
demand like demand buffers; the differ- 
ence is that the limit count can be used 
to limit those allocated for a given pur- 
pose, as represented by the associated 
limited buffer pool ID. 


SM passes the limited buffer pool ID to 
HS. When HS receives a pacing response 
from its pacing partner with a new send 
pacing window size, it adjusts the limit- 
ed pool limit count to include the new 
send pacing window size. 


RM passes the limited buffer pool identi- 
fier to PS after receiving it from SM. 
PS uses a limited buffer to send a 
normal-flow request to HS. If the limit- 
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ed pool is empty (1.e., the limit count 
is 0), PS waits until permission to send 
a new pacing window is received for the 
session and HS adjusts the pool. This 
keeps PS from flooding HS with 
normal-flow requests that cannot be sent. 


The limited pool is set up to allow 
limited-buffer requests (from PS). When 
PS requests a limited buffer and the send 
residual pacing count (which the limit 


count represents) has gone to 0, the. 


request is queued until HS adjusts the 
send residual pacing count to a value 
greater than 0, which occurs when HS get 
a pacing response from its partner HS. 


PERMANENT BUFFER POOL 


The unique characteristic of the perma- 
nent buffer pool is that, after a buffer 
is gotten from a permanent buffer pool, 
it is returned to that pool when it is 


freed. If all the buffers in the pool \_— 


are in use, no more buffers can be taken 
from the pool until one of the buffers is 
freed. After a permanent buffer pool is 
created, the number of buffers associated 
with it is adjusted, by SM, when HS 
instances are created (increased) or 
destroyed (decreased). 


Link buffers are a special Kind of perma- 
nent buffer with additional restrictions. 
When a DLC is created, it is assigned a 
pool of link buffers. 
received from the link connection, it is 
placed in a Link buffer from the assigned 
pool and sent to path control. When the 
buffer is freed, it is returned to the 
pool assigned to the DLC (the same as 
other permanent buffers). Link buffers 
cannot be sent to a process that waits 
for an external event to occur (for this 
could potentially cause a deadlock). The 
process always has to be able to run, 
process the link buffer, and free it 
without waiting on any outside event to 
occur. Received link buffers are not 
reused for responses or acknowledgments,» 
since the DLC may delay sending them. 
link buffers are used within the session 
layers whenever they will be quickly 
freed. 


The LU uses other permanent buffers for 
sending responses » exped1 ted- flow 
requests, and IPM acknowledgments. A 
node component may call BM to get .a per- 
manent buffer first; if the buffer is not 
available, it may then ask for a demand 
buffer instead. In such a case, if the 
demand buffer is not available either, 
the calling process (if 1t does not wait) 
ends abnormally. 


FIXED AND VARYING DYNAMIC BUFFER POOLS 
Fixed and varying dynamic buffers are 
used for session-level fixed and adaptive 


pacing, respectively. 


that it receives from PC in link buffers. 


HS uses dynamic 
buffers to store normal-flow requests ~ 


When a BTU i 


—_ 


” 


When a normal-flow request is received, a 
dynamic buffer is taken from the pool and 
the request is copied to this buffer by 
HS. 


For adaptive pacing, when the buffer 
flagged PAC is freed by PS, BM will then 
(when sufficient storage exists) send a 
BUFFERS_RESERVED signal to HS indicating 
how many new buffers have been reserved 
for its pacing partner to fill. Based on 
the BUFFERS_RESERVED signal, HS builds 
and sends a pacing response (1.e., IPM) 
to its pacing partner, informing it that 
it now has permission to send another 
pacing window. (An IPM carries’ the 
next-window size, corresponding to the 
number of buffers reserved by BM, which 
reflects the availability of storage and 
the RLWI setting BM detected in the freed 
buffer carrying PAC.) The pacing partner 
updates its send residual pacing count 
upon receiving the pacing response. (See 
"Chapter 6.2. Transmission Control" for 
details. ) 


The new window size reserved by BM for 
adaptive pacing can change _ from one 
FREE_BUFFER time to the next. At 
FREE_BUFFER time, if the buffer freed is 
flagged with PAC and RLW, it actually 
notifies BM to not only allocate a new 
window but also a bigger one than the 
current one. Depending upon the avail- 
ability of dynamic buffers, BM may delay 
the reservation of the new window, it may 
decrease the size of the new window, it 
may maintain the size of the new window, 
or, if buffers are available and the 


buffer freed is flagged with PAC and RLW; 


it may increase the size of the new win- 
dow. When BM runs critically short of 
varying dynamic buffers, it notifies HS 
via the REDUCED version of  BUFF- 
ERS_ RESERVED. This causes TC to reset to 
0 the size of the current window by send- 
ing an unsolicited pacing message (see 
"Chapter 6.2. Transmission Control" in 
Chapter 6.2 for details). 


For fixed pacing, when the buffer flagged 
with PAC is freed by PS, BM sends a BUFF- 
ERS_RESERVED signal to HS indicating that 
enough dynamic buffers are reserved to 
receive another window from its partner 
HS. The size of the window is fixed dur- 
ing session initiation. When a shortage 
of fixed dynamic buffers exists, BM 
delays sending BUFFERS_RESERVED to HS 
until enough buffers are again available. 
Having received the BUFFERS_RESERVED sig- 
nal, HS builds and sends a= pacing 
response to its partner HS informing it 
that it now has a grant for another send 
window. 


For either adaptive or fixed pacing, the 
partner HS updates its send residual pac- 
ing count after receiving the pacing 
response and increases the number of 
buffers in its limited buffer pool by the 
size of the new (varying or fixed) pacing 
window (see "Chapter 6.2. Transmission 
Control"). 

When a dynamic buffer is freed, it is not 
returned to the pool it was taken from; 
instead, BM makes it available for real- 
locating wherever it is then needed. 
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Figure B-1 summarizes the different types of 
session-managed data and the usage of buff- 


ers. 


Buffer Usage 


Component 
Requesting Buffers 


Sending normal-—flow data requests: PS 
PS uses limited buffers to 
send normal—flow data requests 
to HS, and HS passes them on 
to other processes. 


Sending expedited—flow requests: 


HS uses permanent buffers to 


HS,» PS 


send CRV. 
PS uses permanent buffers to 
send SIGNAL RUs to HS for 
forwarding to the partner LU. 


Sending responses: 


HS, PS 


All buffers for sending responses 
come from the permanent buffer 
pool (e.g.» IPM, IPR,» IPM_ACK, 
RTR_RSP, SIGNAL_RSP, SEND_ERROR, 
CONFIRMED ) 


Sending normal—flow DFC requests: HS 

Special normal—flow requests 

(i.e., BIS, RTR» and LUSTAT) 

are sent using permanent buffers. 
When each such request needs to 

be sent out and limited buffers 

are not available, HS cannot wait 

for a buffer; hence, HS uses a 
permanent. buffer to send the record 
instead of a limited buffer. 

However, the limited buffer pool 

size is adjusted by HS to reflect the 
correct send residual pacing count. 


Receiving normal—flow requests: HS 
HS uses a fixed or varying dynamic 
buffer to hold the received 
normal—flow request received 
from PC so that the link 
buffer can be released. 


NOTES: 


Buffer Type 
Required 


limited 


(Note: 1) 


permanent 
(Notes 2, 3) 


Oe 


permanent 
(Notes 2, 3) 


permanent 
(Note 2) 


dynamic 


C ; 


1. If a limited buffer is not available, PS suspends processing and waits for one unless the limited 
buffer pool has been destroyed. (A race condition may have occurred in which HS was destroyed and 


all buffer pools HS owned were also destroyed. ) 


requests a demand buffer instead. 


2. If no permanent buffer is available, a demand buffer is requested instead. 


In the absence of the limited buffer pool, PS 


If that fails, the 


calling process ends abnormally (which causes an UNBIND to flow). 


3. Upon receipt, these RUs remain in the link buffers from DLC until they are processed and freed, 
or HS transfers them to local (not paced) storage that is not managed by the buffer manager. 


Figure B-1. 


Send/Receive Buffer Usage (for Session Data) 
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BUFFER MANAGER PROTOCOL BOUNDARY 


LU components (1.e., RM,» SM, PS, HS) and BM 
communicate using the following protocol 
boundary. 


LU TO BM 

The following signals are included as parame- 
ters in synchronous (Call) invocations of BM: 
¢ ADJUST_BUF_POOL 


e  CREATE_BUF_POOL 


® DESTROY_BUF_POOL 


® FREE_BUFFER 
® GET_BUFFER 


With each call to BM, other appropriate 
parameters are also passed. When BM adds 
buffers to a fixed or varying dynamic pool as 
part of a FREE_BUFFER or ADJUST_BUF_POOL 
action, BM notifies HS by sending a BUFF- 
ERS_RESERVED signal, indicating that the num- 
ber of buffers available in the pool has 
changed. If the HS instance no longer exists 
at FREE_BUFFER time, BM does not send the 
BUFFERS_RESERVED signal. 


Following are detailed descriptions of the 
LU-BM calls. 
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ADJUST BUF POOL 


The ADJUST_BUF_ POOL call to BM is a request 
to change the capacity of an existing pool, 
or to change the number of buffers in a pool 
without changing the pool capacity. The new 
capacity can be specified to be larger or 
smaller than the current pool capacity, to be 
restored to its original capacity (at pool 
creation time), or (for varying dynamic 
pools) to reduce the capacity to the amount 
requested by BM to conserve system dynamic 
storage. 


ADJUST_BUF_POOL can also request immediate 


replenishment action in order to bring the. 


number of buffers available in the pool up to 
the current pool capacity. 


An ADJUST_BUF_POOL call to BM contains the 
following parameters: 


e Pool ID 


e The number of buffers to be added to or 
subtracted from the pool capacity (for 
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permanent pools) or the limit count (for 
limited pools). If buffer resources are, > 
limited and cannot be allocated to the(— 
process at ADJUST_BUF_POOL time, the —~ 
ADJUST_BUF_POOL Call fails with no change 

to the number of buffers associated with 


the pool. 


An indication to reset the number of 
buffers in the pool (and capacity) to the 
initial value set by CREATE_BUF_POOL, and 
canceling any pending replenishment 
action triggered by a previous GET_BUFFER 
specifying PAC, but whose buffer has not 


yet been freed; or to leave the current 


pool size (for fixed and varying dynamic 
pools) unchanged, but to perform a pend- 
ing replenishment action immediately 
(rather than at the later FREE_BUFFER 
time); or (for varying dynamic pools) an 
indication that the pool size may be 
reduced to the size specified by BM in .—~ 


its previous BUFFERS_RESERVED- signal, 
e.g.» because an IPM acknowledgment has 
Since been received. 


7 
a imc 


— 


C | 
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CREATE BUF POOL 


The CREATE_BUF_POOL call to BM requests BM to 
create a buffer pool of a specified type: 
permanent, fixed dynamic, varying dynamic, or 
limited. For permanent, fixed, and varying 
pools, BM creates the specified number and 
size of buffers, and holds them until they 
are called for (see GET_BUFFER call). For 
limited pools, the buffers are created (allo- 
cated) at GET_BUFFER time. 


The BUFFERS_RESERVED signal is not sent for 
this initial reserve action. 


When a process is destroyed for any reason, 
all buffer pools owned by that process are 
automatically unreserved. If a buffer pool 
is being reserved by one process for another 
process, the latter process already exists 
(has already been created) when the CRE- 
ATE_BUF_POOL call is made. 


A CREATE_BUF_POOL call to the BM contains the 
following parameters: 


e Pool type (permanent, fixed, varying» or 
limited). 


e The capacity (pool size) of the buffer 
pool. This pool size does not represent 
the number of buffers in the pool at any 
one time but rather the capacity of the 
pool to hold buffers (analogous to the 
size of a swimming pool versus the amount 
of water in it). 


—- For permanent and fixed pools, it is 
the number of buffers initially put 
in the pool. 


—- For fixed pools, this is also the 
number of buffers that BM adds to the 
pool when replenishing it. 


- For varying pools, this parameter is 
a performance-related “target," not a 
minimum or maximum pool size. 


- For limited pools, this pool size is 
used to set an initial value in a 
limit count field, N. If N = 0, BM 
suspends the caller, if the Wait 
option on the GET_BUFFER call was 
specified, until it can supply the 
buffer; otherwise, the GET_BUFFER 
call fails to return a buffer. Each 
GET_BUFFER call decrements N by 1. 
An ADJUST_BUF_POOL call to BM is used 
to increment or decrement N. The 
running value of N is equal to the 
current send residual pacing count. 


- For limited pools, “no-limit" may be 
specified, in which case BM does not 
limit the number of buffers that can 
be associated with, and thus obtained 
from, the limited pool. Any 
ADJUST_BUF_POOL call for the limited 
pool is ignored. 


e The size of each buffer (e.g., 256 bytes) 
to be reserved by the BM for the pool, 
where all buffers in a pool are the same 
size. 


e For varying pools, an initial number (or 
“increment") of reserved buffers (default 
of 1) in the pool. (The model described 
in this book sets this to 1.) A multiple 
of this increment value is used at pool 
replenishment time. 


e The pool owner, which becomes the recipi- 
ent of the BUFFERS_RESERVED signal (from 
BM). The specified owning = process 
instance exists at reserve time. The 
pool is deleted when the owning process 
issues a DESTROY_BUF_POOL call (with All 
specified). 


BM sets a return code indicating whether the 
buffer pool was created successfully or not 
(e.g.» buffer storage not available); if suc- 
cessful, BM returns the pool ID. 
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DESTROY BUF POOL | A DESTROY BUF POOL call contains the follow- 
ing parameters: 


The DESTROY_BUF_POOL call to the BM requests e A specific pool ID, or an indication that -—~ 


that a specified buffer pool or all buffer the request applies to all owned pools. 
pools owned by the caller be destroyed. 
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FREE BUFFER 


The FREE_BUFFER call to BM notifies BM that 
the specified buffer is no longer required 
and needs to be released. A process does not 
have to "own" the pool to free a buffer from 
it. Any process with addressability to the 
buffer can free it. For example, 


e If the buffer is a demand buffer, it is 
returned to general system storage (de- 
stroyed). 


e §6If the buffer is a permanent buffer, it 
is immediately returned to its permanent 
pool (rereserved). 


e 6 If the buffer is from a fixed or varying 
dynamic pool, it is returned to the sys- 
tem. When the buffer being freed is one 


that held a pacing request, BM adds a 
number of buffers to the pool from which 
the freed buffer was obtained, where the 
number is the size of the new pacing win- 
dow that can be received. BM informs the 
process (e.g.» HS) owning the pool of the 
new buffers by sending it a BUFF- 
ERS_RESERVED signal. 


e If the buffer is a limited buffer, its 
freeing does not increment the limit 
count being maintained for its limited 
pool. (The value of the limit count is 
incremented only with the ADJUST_BUF_POOL 
call to the BM.) 


A FREE_BUFFER call to BM contains a pointer 
to the buffer that needs to be freed. This 
pointer was returned from a_ previous 
GET_BUFFER call to BM. 
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GET BUFFER 


The GET_BUFFER call to BM requests one or 
more buffers for use. The calling process 
becomes the owner of the buffer. However, HS 
is the owner of all buffer pools used by the 
LU. 


A GET_BUFFER call to BM contains the follow- 
ing parameters: 


@ A pool ID, returned from a previous CRE- 
ATE_BUF_POOL call, which is used to iden- 
tify the pool from which the buffer is to 
be allocated; or a demand buffer request 
(including buffer size needed). 


e For fixed and varying dynamic pools, 
information specifying the Pacing (PAC or 
-PAC) and Reserve Larger Window (RLW or 
“RLW) indicator values in the MU for 
which the buffer is to be used. If PAC 
1s specified, it means that when the 
buffer is later freed, BM should reserve 
buffers for the next pacing window and 
add them to the pool. For fixed pools; 
if the required number of buffers cannot 
be created at free-buffer time, the 
requested replenishment action is delayed 
until they are available. For varying 
pools, the number of buffers BM adds to 
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the pool depends on multiple factors: 
the availability of general system stor- 
age, the status (held or freed) of buff- 
ers previously obtained from the pool, 
the setting of RLWI, and the value of the 
increment (I) specified in the call cre- 
ating the pool. When general system 
storage is low, BM may reduce the number 
of new buffers added to the pool by a 
multiple of I, to allow immediate replen- 
ishment of the pool. When sufficient 
storage exists, BM adds C buffers to the 
pool (C = current window size) if RLWI = 
~RLW, or C + nI buffers (where n is some 
positive integer) if RLWI = RLW. When BM 
does replenish a pool following the sub- 
sequent freeing of the corresponding 
buffer, it sends a BUFFERS_RESERVED sig- 
nal to the pool owner. 


e An indication ("wait" or “no wait") 
whether or not the calling process may be 
suspended pending availability of a buff- 
er to honor the request. When the proc- 
ess may not be suspended, BM returns an 
appropriate return code to indicate that 
the pool is empty or that a demand buffer 
cannot be created. 


When the requested buffer is available, BM 
returns the buffer pointer to the calling 
process. 


( 


ye 


ese 
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BM TO LU 


The BUFFERS _RESERVED signal is sent asynchro- 
nously from BM to HS. A detailed description 
follows. 


BUFFERS RESERVED 


The BUFFERS_RESERVED signal is sent by BM to 
a dynamic buffer pool owner (e.g., HS) to 
report a change, other than as a result of a 
GET_BUFFER, in the number of buffers avail- 
able in a dynamic buffer pool. The BUFF- 
ERS_RESERVED signal contains the following 
parameters: 


e The pool ID 


e¢ The number of buffers added to the pool 
if this signal follows a FREE_BUFFER of a 
Pacing request buffer, or to be sub- 
tracted from the pool if a REDUCED action 
1s being reported (see below) 


¢ The number of buffers currently in the 
pool (available for GET_BUFFERs ) 


e The type of action being reported: 


- ADJUSTED: An ADJUST_BUF_POOL request 
has been honored. 


— REPLENISHED: A dynamic buffer pool 
has been replenished as a result of a 
FREE_BUFFER of a pacing request buff- 
er. 


— REDUCED: BM has detected a critical 
scarcity of system storage and will 
reduce the number of buffers assigned 
to the varying dynamic pool (possibly 
to 0) when the pool owner issues an 
ADJUST_BUF_POOL (following exchange 
of unsolicited and reset acknowledg- 
ment IPMs with the partner LU). 


— RESTART: BM has changed the number 
of buffers in the varying dynamic 
pool from 0 to aéepositive value 
(1.e., the value of the increment 
specified in the CREATE_BUF_POOL for 
the pool); this signal follows the 
REDUCED (to 0) type BUFFERS_RESERVED 
Signal when node congestion eases. 


The BUFFERS_RESERVED message is of sufficient 
size that it can itself be reused to send an 
IPR or IPM. If this message is not reused to 
send an IPR or IPM, it is freed by the mes- 
Sage receiver. | 
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SEND_DATA : 
(80 bytes) GET_BUFFER( limited pool ID, wait) ; ‘ 
Lorri wm rem nwr wr rrr ree >o ‘ : ; 
(80 bytes copied into the limited buffer) , | ‘ 
2 aueet——______IRU1(size=200) : ; ; 
SEND_DATA ‘ ‘ : ; 
(80 bytes) : : 
30 ; ; ‘ ‘ 
(80) (80) é . ; . 
4 weueleeent—tRu1(RU size=200) . ; ; 
SEND_DATA : : : ; 
(80 bytes ) ‘ : ‘ : 
=—_—_—_—>0 ; ° “ ‘ 
(80) (80) (40) . ‘ 
6 seeeloeeeetoetRUI(RU size=200) . : 
MU(SEND_DATA_RECORD) MU(SEND_DATA_RECORD, PAC, RLW) 
7 === Se eo . 
GET_BUFFER(no wait, 
: demand buffer size)/(100 bytes) ; 
8 GET_BUFFER( limited pool ID, o<— — — — — — — o-samenl (BTU size=100) 
wait) : 4 
9 j<~_s-s-e- eee ere ene ee >o data segment #1 
10 (40) : 5 >o-———-> 
11 we—t___Ipy2 FREE_BUFFER( pointer to demand buffer ) 
12 (RU size=200) Of—- —- - eke eer ere eer emo 
GET_BUFFER(no wait» . * 
demand buffer size). (100) : 
13 o- ------ o-saneet (BTU size=100) 
. : data segment #2 
14 FREE_BUFFER( pointer to limited buffer) >o——> 
15 ‘ oS SS Se 
‘ - FREE_BUFFER(pointer to demand puffer) 
16 a 
Notes: 
1. The signal names (e.g.,», GET_BUFFER) above the dashed lines 
refer to parameters (identifying request types) passed in Call 
invocations of the buffer manager; the additional parameters 
in parentheses are also passed to BM. 
2. The symbol "#888" denotes the data stored in the buffer. 


Figure B-2. LU Interactions with BM When Sending Data 
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data segment #1 . MU (PAC, RLW) 


See a ee ASR ce OE Re ee ee ‘ .10 
, . GET_BUFFER( dynamic pool ID; 
é no wait, PAC, RLW) ;‘ . 
: ; oS = SS SS ‘ ll 


(Copy record from link : 
buffer to dynamic buffer.) . 


: o<- ------ ;-ssene! seg #1. 12 
. FREE_BUFFER(pointer to Link sutterd , : 
: 0 SSS : «lS 
data segment #2 . MU ‘ . seg #2 seg #1. 


——>Q9—_—— << > > > ele data “14 


. FREE _BUFFER( pointer to link ees ee 
. OS SS - 16 


FREE_BUFFER( pointer to dynamic pur ier) 
C6 SS Se Se Se 17 


BUFFERS_RESERVED( REPLENISHED, 
total number in pool, pool ID, . 


‘ number of new buffers reserved). . 
oe eornrneeen OOO e e 18 


Figure B-3. LU Interactions with BM When Receiving Data 
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The comments below correspond to the numbers. 


in Figure B-2 on page B-12 and Figure B-3 on 
page B-13. 


1. In node A> a transaction program (TP) 
issues a SEND_DATA verb; this causes PS 
to call BM to request a limited buffer to 
store the data from TP. If a limited 
buffer is not available at this time, PS 
will request a demand buffer instead (see 
Chapter 5.1). The amount of data that PS 
can copy to its limited buffer depends on 
the size of the limited buffer, which 
cannot be greater then the maximum RU 
size. (The session manager [SM] previ- 
ously created, via a CREATE_BUF_POOL Call 
to BM, a limited buffer pool for the ses- 
sion components to send _  wnormal-flow 
requests, and set the buffer size to the 
maximum RU size obtained from the BIND. ) 
In this example, the maximum RU size is 
200 bytes. 


2. In node A, PS copies the data from the TP 
storage to the PS-owned limited buffer 
obtained from the limited buffer pool. 
(In this example, 80 bytes have been sent 
by the TP.) PS copies the 80 bytes of 
data to its limited buffer but does not 
send it until the whole buffer is full. 


3. The TP requests more data be sent to its 
partner TP in node B. 


G4. In node A, PS copies another 80 bytes of 
data from the TP storage to the limited 
buffer (the same buffer as above). In 
this example, 160 bytes of data have now 
been stored in the limited buffer. 


5. The TP requests more data be sent to its 
partner TP in node B. 


6. In node A, PS copies another 40 bytes of 
data from TP storage to the same limited 
buffer as above. The limited buffer now 
contains 200 bytes of data and is full. 
Any additional data (1.e., 40 bytes in 
this example) in the TP storage is copied 
to a new limited buffer; PS sends the 
full buffer first, then gets a new buffer 
to copy the rest of data. (If no more 
data is left in the TP storage when the 
limited buffer is filled, PS does not 
send the contents of the filled buffer 
until the end-of-chain indication is 
received from the local TP. ) 


7. In node A» PS sends the RU, 
MUCSEND_DATA_RECORD), to HS. In this 
example, HS sets the Pacing indicator and 
Request Larger Window indicator to PAC 
and RLW (see "Chapter 6.2. Transmission 
Control"), respectively. The RLW value 
requests that the new send pacing window 
be larger than the current one. 


8. In node A, PC receives the MU from HS and 
calls BM, requesting the first demand 
buffer to begin segment generation. The 
number of segments that are generated 
depends on what the maximum send BTU size 
is (1.e., 100 bytes in this example). 
(See SNA Type 2.1 Node Reference for more 
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10. 


ll. 


12. 


13. 


14. 


details on segment generation.) This 
example assumes that segment generation 
is supported. If segment generation is 
not supported, the MU will remain in the 
same buffer (1i.e., the PS-owned limited 
buffer) and be sent to DLC by PC. DLC 
then frees that limited buffer after the 
data is sent to node B. 


In node A, PS calls BM to obtain another 
limited buffer to store the remaining TP 
data. | 


In node A, PC sends the first BTU (which 
contains 100 bytes of data) to DLC, and 
DLC sends it to node B. In node B, when 
the first segment (which contains the 
first 100 bytes of the record, 
MUTSEND_DATA_RECORD] is received by PC 
(in a link buffer allocated by DLC, a 
process not defined in detail in this 
book), the data remains in the Link buff- 
er (a DLC-owned buffer) and is passed to 
HS. Note: Segment reassembly is a PC 
function (on the receive side) and is 
done only when segment generation is done 
by the PC on the send side. Segment 
reassembly function is actually done in 
the transmission control (TC) process 
(see "Chapter 6.2. Transmission Control" 
for more details on segment reassembly). 


In node A» PS copies and stores in a new 
limited buffer the unsent 40 bytes of 
data. This RU will be sent to HS when 
its buffer becomes full. In node B, HS 
calls BM to request a dynamic buffer toa 
store the record, MU(SEND_DATA_RECORD), 
and sends it to PS later. The dynamic 
buffer pool was previously created by SM 
for the session. In node B, the size of 
the dynamic buffer (receiving the paced 
normal-flow request) is the same as the 
size of the limited buffer (sending the 
paced normal-flow request) in node A. HS 
also informs BM that node A has requested 
a new and larger send pacing window by 


passing the PAC and RLW indications in 


its GET_BUFFER request. 


In node A, the demand buffer that the BTU 
was in is freed (returned to BM) by DLC 
after the first BTU is sent. This free- 
ing action is asynchronous with the PC 
allocation of the demand buffer for the 
next segment. The order of their occur- 
rence may vary from the example.) In 
node B, HS copies the record (in this 
example, it contains 100 bytes) from the 
link buffer to the newly obtained 
HS-owned dynamic buffer. 


In node A, PC calls BM for another demand 
buffer to send the remaining 100 bytes. 
In node B, the link buffer is released 
(not reused by HS). 


In node A, PC sends the second BTU to 
DLC. In node B, when the second segment 
that contains the last 100 bytes of the 


record is received by PC, the aaher , 
ee 


remains in the link buffer (a DLC-owned 
buffer) and is passed to HS. HS copies 
the second segment from the link buffer 
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15. 


16. 


to the same dynamic buffer (which con- 
tains the first segment). The buffer 
contains 200 bytes and is now full. 


In node A; PC returns the limited buffer 
that the MU(SEND_DATA_RECORD) was in to 
BM. In node B, HS sends the whole RU 
(which was reassembled from the first and 
second segments) to PS. PS then passes 
it to TP. 


In node A, the demand buffer that the 
second BTU was in is returned to BM by 


17. 


18. 


DLC after the second BTU has been sent. 
In node B, the link buffer is released. 


In node B, PS returns the dynamic buffer 
to BM after passing the whole RU to TP. 


In node B, BM sends a BUFFERS_RESERVED 
signal to HS, which indicates a new send 
window for node A. This is because the 
buffer freed in step 17 was the one that 
received the PAC and RLW indications. 
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GET_BUFFER( Link pool ID, no wait) IPM 


O-+ «© e e e@ ee e 


lL. . 0S eS Se SS Se eS ee o< 
; : ; . IPM(solicited, 
, : MUC(IPM, solicited, NWS=2) . NWS=2) 
2 . : rtm FL 
: ‘ ADJUST_BUF_POOL( limited pool ID, + NWS buffers) 
3 ° ® SS Se >o ® e 
; ‘ FREE_BUFFER(pointer to link buffer) ; 
G . : SS a tee Sas >o : : 
Note: 


The signal names (e.g., GET_BUFFER, ADJUST_BUF_POOL, FREE_BUFFER) 
above the dashed lines refer to parameters (identifying request types) 
passed in Call invocations of the buffer manager; the additional 
parameters in parentheses are also passed to BM. 


Figure B-4. Receiving a Solicited IPM 
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C) 


- 


! 


So 


BUFFERS_RESERVED( REPLENISHED, 


; ’ total number in pool, pool ID, . : 
; : number of new buffers reserved) . : 

; : oO R - tl 
IPM(solicited, NWS=2) MU( IPM, solicited ,NAS=2)| ; ‘ 
<_< 0¢ ‘ Panes 

FREE_BUFFER(pointer to demand buffer) ‘ ; : 
en Ser ee ee ee a ee ee ee ee ee Pe) e e ° 3 


Note: 


The signal names (e.g., FREE_BUFFER) above the dashed lines refer to 
parameters (identifying request types) passed in Call invocations of the 
buffer manager; the additional parameters in parentheses are also passed 
to BM. 


Figure B-5. Sending a Solicited IPM 
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SNA LU 6.2 Reference: 


Figure B-4 on page B-16 and Figure B-5 on 
page B-17 show receiving and sending a 
solicited IPM. In this example, BM has 
been informed previously that HS in node 
A requested a larger send pacing window 
(see Figure B-3 on page B-13). 


The comments below correspond to the num- 
bers in Figure B-4 on page B-16 and Fig- 
ure B-5 on page B-17. 


In node B;, BM sends a BUFFERS_RESERVED 
signal to HS to indicate more buffers are 
reserved for the buffer pool used to 
receive paced data from node A. In node 
A, the IPM received from its partner in 
node B is stored in a link buffer by DLC. 


In node B, HS reuses the demand buffer 
that the BUFFERS_RESERVED signal was in 


Peer Protocols 


and builds a solicited IPM. HS sends the 
IPM to node A through PC and DLC. The 
IPM contains a next-window size (NWS). 
In node A, the solicited IPM is sent to 


HS via PC. 


In node B, the demand buffer is returned 
to BM after the IPM is sent to node A. 
In node A», upon receiving the solicited 
IPM, HS adjusts the limited pool Limit 
count to the new send residual pacing 
count (via ADJUST_BUF_POOL) to reflect 
that a grant for a new send window has 
been received. 


In node A, the link buffer is returned to 
BM after the IPM is processed. Now node 
A can use the new window grant to send 
more normal-flow requests to node B. 


C -* 


APPENDIX N. FSM NOTATION 


A finite-state machine (FSM) is a combination of processing and memory, where the memory con- 
sists of the state of the FSM. The state can take one of a small number of named values (the 
state names). An FSM is defined by a matrix that lists the states and specifies the processing 
to be performed when the FSM is called. This processing typically depends on the current state 
of the FSM and on the input passed to the FSM, and may change the FSM state (resulting in a 
state transition) and produce output. Within this matrix definition, each state is given a num- 
ber as well as its name, for notational convenience. 


A number of alternative FSM definitions may be grouped together as a generic FSM, the definition 
to be used being assigned dynamically. The assignment of a particular definition to be used at 
a given time is called the binding of the generic FSM. A generic FSM can also be assigned to be 
a "no operation." A generic FSM 1s identified by the pound sign (#) prefix, e.g.» #FSM_BIS. 


The following operations are performed on an FSM: 


e Call. Processing is performed as defined in the FSM definition for the existing combination 
of current state and input. This may involve a state transition. 


e State check. Validity checking is performed for the existing combination of current state 
and input. 


e State test. The current state of the FSM is tested for equality or inequality with a speci- 
fied value. 


An FSM is represented by a state-transition matrix. 


The syntax of the state-transition matrix FSM definition is shown in Figure N-1 on page N-2. 
The column headings give the FSM state names, while the row headings name the inputs to the 
FSMs. The matrix elements—(row,column) intersections—define the state transitions and output 
actions. 


Horizontal lines are used to group input lines together to improve readability. Their location 
has no bearing on the FSM function. For compactness, mnemonic abbreviations are used in the 
matrices. 


The input lines within the matrix are scanned from top to bottom at execution time. The first 
input line found with all its conditions true is used to address the matrix for the next state 
and the output code. No more than one input line in a matrix has all its conditions true during 
a scan. = 


An FSM comes into existence initialized to state 1. If another state is to be the initial 
state, the FSM is initialized explicitly by calling the FSM with an appropriate signal. 


Calling an FSM executes the FSM; 1.e., an FSM action code is selected based on the current state 
of the FSM and the input line that is true. The input line evaluation uses the parameters or 
Signal passed to the FSM. The FSM is scanned for a true input line from top to bottom of the 
matrix. 


If the next-state indicator is a number n, the FSM enters state n. If the next-state indicator 
is a state-check indicator (>), the call of the FSM would act as if a no-state-change indicator 
(-) were encountered. (In practice, the formal description checks for such conditions prior to 
calling an FSM in order to perform special error handling.) If the next-state indicator is a 
cannot-occur indicator (/), this is an execution-time error; calls of the FSM cannot encounter 
this indicator because previous logic has filtered out the input for that state of the FSM. 


If no input line is true, the call acts as if a no-state-change indicator (-) were encountered. 
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N-2 


fname: 


STATE NAMES----> 


INPUTS STATE NUMBERS--> 


OUTPUT FUNCTION 
CODE 
oc-1 


Output logic statements 


Output logic statements 


Legend 
[ ] = optional parameter 
fname = FSM name 


snam = state name component 


1c = input condition name 
ac = action code 


An action code (ac) has the syntax: ns{(oc)], where: 
next-state indicator 


output code (The parentheses around the oc are 
sometimes omitted to save space. ) | 


ns 
oc 


Possible next-state indicators and associated action code 
formats are: 


n[(oc)] normal state transition to state n (corresponding 
to some snum)} 
-[(oc)] same-state transition—remain in the same state 
>{(oc)] error condition, no state change 
/ "cannot occur" condition, no state change 


Figure N-l1. Syntax of an FSM State-Transition Matrix 
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ACT 


API 


ASCIT 


ASM 


BBI 


BBIU 


BBIUIT 


BC 


BCI 


BETB 


BIND 


BIS 


BIU 


BM 


CD 


CDI 


CEB 


CEBI 


CINIT 


CNOS 


TERMINOLOGY: ACRONYMS AND ABBREVIATIONS 


activate 
application programming interface 


American Standard Code for Informa- 
tion Interchange 


address space manager 


Begin Bracket 

Begin Bracket indicator 
Begin Basic Information Unit 
BBIU indicator 

Begin Chain 


Begin Chain indicator 


‘between brackets 


BIND SESSION 
BRACKET INITIATION STOPPED 
basic information unit 


buffer manager 


Change Direction 

Change Direction iHdacatoe 
Conditional End Bracket 
Conditional End Bracket indicator 
CONTROL INITIATE 


change number of sessions 
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CONLOSER' contention-loser 


CONWINNER contention-winner 


COPR control operator services 
cos class of service 
cP control point 
CRV CRYPTOGRAPHY VERIFICATION 
CT correlation table 
DAF Destination Address field 
DES Data Encryption Standard 
DFC data flow control 
DIA Document Interchange Architecture 
DLC data link control 
DR1 Definite Response 1 
DR1I Definite Response 1 indicator 
DR2 Definite Response 2 
DR2I Definite Response 2 indicator 
DSU distribution service unit 
EB End Bracket 
EBI End Bracket Indicator 
EBIU End Basic Information Unit 
EBIUI EBIU indicator 
Terminology: Acronyms and Abbreviations T-1 


EC End Chain HDX-FF HDX flip-flop — 


ECI End Chain indicator HS hal f-session 
ED Enciphered Data HSID half-session identification 
EDI Enciphered Data indicator 
ID identifier, identification 
EFI Expedited Flow indicator 
INB In Bracket 
ERI Exception Response indicator 
INIT-SELF INITIATE-SELF 
ERP error recovery procedures | 
IPM ISOLATED PACING MESSAGE 
ESD extended sense data * 
IPR ISOLATED PACING RESPONSE : 
EXP expedited 
LFSID local-form session identifier 
EXR EXCEPTION REQUEST 
LIC last in chain (~BC, EC) 
FDX full-duplex LL logical record length (prefix) 
FF flip-flop | LLID logical record length and GDS a 
(prefix) ae 
FI Format indicator 
LU logical unit 
FIC first in chain (BC, -EC) 
LUCB LU control block 
FM function management 
LUSTAT LOGICAL UNIT STATUS 
FMD function management data | fos 
LUW logical unit of work a | 
FMH FM header 
MC mapped conversation 
FMP FM profile 
MCR mapped conversation record 
FQPCID Fully Qualified Procedure Corre- 
lation Identifier 
MGR manager 
FSM finite-state machine 
MSG message 
FSP first speaker 
MU message unit 
GDS general data stream 
NAU network addressable unit S 
HDX hal f-duplex NC network control 
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NEG 


NG 


NOF 


NTWK 


NWS 


OAF 


ODAI 


OIc 


PAC 


PB 


PC 


PCID 


PD 


PDI 


PI 


PIP 


PIU 


PLU 


POS 


PRI 


PS 


PS .CONV 


PS.COPR 


negative 

no good 

node operator facility 
network 


next-window size 


Origin Address field 
OAF-DAF Assignor indicator 


only in chain (BC, EC) 


Pacing Request, Pacing Response 
(value of PI in RH) 


protocol boundary 
path control 


procedure correlation identifier 


Padded Data 


Padded Data indicator 

Pacing indicator 

program initialization parameters 
path information unit 

primary LU 

positive 

primary 

Pigeminn tte Service: 


presentation services for (basic) 
conversation 


presentation services for the con- 
trol operator 


PS.CRPM 


PS.SPS 


PS .MC 


PTR 


QRI 


RC 


RCB 


RCV 


RESYNC 


RH 


RLWI 


RM 


RPC 


RQ 


RQD 


RQE 


RQN 


RRI 


presentation services~-conversation 
services resource manager 


presentation services--sync point 
services 


presentation services for mapped 
conversations 


pointer 


physical unit 


queue 
Queued Response 


Queued Response indicator 


receive, receiving 
return code 

resource control block 
receive 


sync point resynchronization serv- 
ice TP 


request/response header 

Request Larger Window indicator 
resources manager 

residual pacing count 

request 


RQ indicating definite-response 


required 


RQ indicating exception-response 


requested 
RQ indicating no-response required 


Request/Response indicator 


Appendix T. Terminology: Acronyms and Abbreviations T-3 


RSP response SQN sequence number ~ 
RTI Response Type indicator Ss session services | 
RTR READY TO RECEIVE SSCP system services control point 
RU request/response unit SSLS source-LU session-limit services 
SVC service; services 
sc session control 
SYNCPT synchronization point 
SCB session control block 
SD Sense Data Included TC transmission control 
e 
SDI Sense Data Included indicator TCB transaction control block oe 
SEC secondary TCCB transmission control control block 
SESS session TERM terminate, terminating, termi- 
nation, terminal 
SESSEND SESSION ENDED 
TH transmission header 
SESSST SESSION STARTED | | TN 
TP transaction program | 
SIG SIGNAL 
TPF transmission priority 
SLDLM session-limit data-lock manager 
TPN transaction program name 
SLU secondary LU 
TS transmission services 
SM session manager | ; 
TSLS target-LU session-limit services “ 
SNA Systems Network Architecture | “7 
TSP TS profile 
SNA/DS SNA Distribution Services 
UNBIND UNBIND SESSION 
SNASVCMG SNA services manager (LU-LU session 
mode name) 
UPM undefined protocol machine 
SNF Sequence Number field 
URC user request correlation 
SON session-outage notification 
VR virtual route 
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SPECIAL CHARACTERS 


(period), to separate name qualifiers 

denoting decomposition 1-5 

_ (underscore), in name phrases 1-5 

| (vertical stroke), to mean "ei- 
ther...or" 1-5 | 

& (ampersand), to indicate composition in 
names 1-5 

* (asterisk), to mean "any value" or "don't 
care" 1-6 


[| 


ABEND_NOTIFICATION 4-5, 4-7 
ABEND_NOTIFICATION structure A-25 
referenced by 
FSM_STATUS 4-87 
HS 6.0-4 
PROCESS_ABEND_NOTIFICATION 4-74 
PROCESS PS_TO_RM_RECORD 3-22 
PROCESS _RECORD_FROM_HS 4-50 
PROCESS _RECORD_FROM_RM 4-49 
PS 5.0-9 
PS ABEND_PROC 3-54 
ABORT_HS 4-7 
ABORT_HS structure A-9 
referenced by 
FSM_STATUS 4-87 
PROCESS _ABORT_HS 4-74 
PROCESS_LU_LU_SESSION 6.0-5 
PROCESS_RECORD_FROM_HS 4-50 
action codes in FSMs 
calling result N-1 
ACTIVATE_NEEDED_SESSIONS procedure 3-24 
referenced by 
CHANGE_SESSIONS_PROC 3-39 
SESSION_DEACTIVATED_PROC 3-72 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
ACTIVATE_SESSION 4-5 
ACTIVATE_SESSION_PROC procedure 5.4-37 
referenced by 
PS COPR 5.4-33 
ACTIVATE_SESSION_RSP 4-5 
ACTIVATE_SESSION_RSP_PROC procedure 3-25 
referenced by 
PROCESS SM_TO_RM_RECORD 3-23 
ACTIVATE_SESSION_RSP structure A-13 
referenced by 
ACTIVATE_SESSION_RSP_PROC 3-25 
BUILD_AND_SEND_ACT_SESS_RSP_NEG 4-58 
BUILD_AND SEND _ACT_SESS RSP_POS 4-58 
PROCESS_SM_TO_RM_RECORD 3-23 
ACTIVATE_SESSION structure A-20 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-24 
ACTIVATE_SESSION_RSP_PROC 3-25 
BUILD_AND_SEND_ACT_SESS RSP_NEG 4-58 
DEACTIVATE_PENDING_SESSIONS 3-47 
FSM_STATUS 4-87 
INITIALIZE _LULU_CB_ACT_SESS 4-70 
PROCESS ACTIVATE_SESSION 4-75 


PROCESS RECORD _FROM_RM 4-49 
SEND_ACTIVATE_SESSION 3-65 
SEND_DEACTIVATE_SESSION 3-68 
ACTIVATE_SESSION verb 5.4-6),) 5.4-21 
processing by PS.COPR 5.4-26 
activation, session 
LU-LU 4-19 
adaptive pacing 
See session-level pacing 
ADJUST_BUF_POOL 


See buffer manager (BM), protocol boundary 


agent 
See sync point, roles, agent 
ALLOCATE_PROC procedure 5.1-11 
referenced by 
MC_ALLOCATE_PROC 5.2-21 
PS CONV 5.1-10 
ALLOCATE_RCB_PROC procedure 3-26 
referenced by 
PROCESS PS _TO_RM_RECORD 3-22 
ALLOCATE_RCB structure A-15 
referenced by 
ALLOCATE_PROC 5.1-11 
ALLOCATE_RCB_PROC 3-26 
CREATE_RCB 3-43 
PROCESS _PS_TO_RM_RECORD 3-22 
TEST_FOR_FREE_FSP_SESSION 3-82 
Already Verified indicator | 
See conversation-level security, Already 
Verified indicator 
API 
See application program interface (API) 
application program interface (API) 2-4 
See also protocol boundary 
closed 2-12 
open 2-12 
application transaction program 2-1 
See also transaction program 
ASSIGN_LFSID 4-12 
ASSIGN_LFSID_RSP 4-12 
ASSIGN_LFSID_RSP structure A-26 
referenced by 
PREPARE_TO_SEND_BIND 4-73 
ASSIGN_LFSID structure A-25 
referenced by 
PREPARE_TO_SEND_BIND 4-73 
ASSIGN_PCID 4-9 
ASSIGN_PCID_RSP 4-9 
ASSIGN_PCID_RSP structure A-23 
referenced by | 
GET_FQPCID 4-70 
ASSIGN_PCID structure A-22 
referenced by 
GET_FQPCID 4-70 
asynchronous transfer 2-7, 2-36 
See also SNA Distribution Services 
(SNA/DS ) 
ATTACH_CHECK procedure 3-26 
referenced by 
ATTACH_PROC 3-30 
ATTACH_ERROR_PROC procedure 5.0-15 
referenced by 
PROCESS FMH5 5.0-10 
Attach FM header (FMH-5) 
See FM header, type 5 (Attach) 
ATTACH_LENGTH_CHECK procedure 3-28 
referenced by 


Index X-1 


ATTACH_CHECK 3-26 
ATTACH_PROC procedure 3-30 
referenced by 
PROCESS _HS_TO_ RM_ RECORD 3-20 
PS_ABEND_PROC 3-54 
ATTACH_SECURITY_CHECK procedure 3-32 
referenced by 
ATTACH_CHECK 3-26 
attaching transaction programs 2-36, 2-44 
See also transaction program, invoking 
remote . 
autoactivation 
See session limits, automatic activation 
automatic session activation 
See session limits, automatic activation 
availability of an LU 
for session initiation 4-9 


back-out 
See sync point, back-out 
Backed Out . 
See sync point, commands, Backed Out 
base function set 2-12 
CNOS functions 5.4-22 
control operator functions 5.4-21 
basic conversation 2-3, 2-12 
See also conversation 
basic conversation message 2-14 
basic information unit (BIU) 2-15 
Begin Bracket indicator (BBI) 
. use 6.1-1; 6.1-4; 6.1-5, 6.1-7; 6.1-10, 
6.1-11, 6.1-12, 6.1-13, 6.1-14, 6.1-16 
Begin Chain indicator (BCI) 
use 6.1-9, 6.1-14, 6.1-15 
bid 
See bracket, bid 
BID_PROC procedure 3-33 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-20 
BID_RSP_PROC procedure 3-35 
referenced by . 
PROCESS_HS_TO_RM_RECORD 3-20 
BID_RSP structure A-11 
referenced by 
BID_PROC 3-33 
BID_RSP_PROC 3-35 
GENERATE_RM_PS_ INPUTS 6.1-36 
PROCESS_HS_TO_RM_RECORD 3-20 
PROCESS RU_DATA 6.1-40 
SEND_RSP_TO_RM_OR_PS 6.1-46 
BID structure A-11 
referenced by 
BID_PROC 3-33 
GENERATE_RM_PS_INPUTS 6.1-36 
PROCESS_HS_TO_RM_RECORD 3-20 
BID_WITHOUT_ATTACH structure A-17 
referenced by 
BIDDER_PROC 3-37 
DFC_SEND_FROM_RM 6.1-21 
bidder 2-8, 2-32 
See also bracket, bidder 
See also contention loser 
BIDDER_PROC procedure 3-37 
referenced by 
GET_SESSION PROC 3-52 
bidding 2-33, 3-6, 3-11 — 
See also bracket, bidding 
bidding with data 
See bracket, bidding 
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BIND 2-8, 2-15, 2-33, 4-19 


' BIND image 


derived from mode name 4-18 
BIND negotiation 2-33 
BIND_RQ_STATE_ERROR procedure 4-52 
referenced by 
PROCESS BIND_RQ 4-76 
BIND_ RSP_STATE_ERROR procedure 4-54 
referenced by 
PROCESS BIND RSP 4-78 
BIND_SESSION_LIMIT_EXCEEDED procedure 4-57 
referenced by 
BIND_RQ_ STATE_ERROR 4-52 
BIS 2-15, 2-34 
BIS (BRACKET INITIATION STOPPED} 6.1-16 
BIS _RACE_LOSER procedure 3-38 
referenced by 
FSM_BIS BIDDER 3-87 
BIS_REPLY structure A-12 
referenced by 
BIS _RACE_LOSER 3-38 
DFC_SEND_FROM_RM 6.1-21 
GENERATE_RM_PS_ INPUTS 6.1-36 
PROCESS_HS_TO_RM_RECORD 3-20 
SEND BIS REPLY 3-67 
BIS RQ structure A-12 
referenced by 
DFC_SEND_FROM_RM 6.1-21 
GENERATE_RM_PS INPUTS 6.1-36 
PROCESS _HS_TO_RM_RECORD 3-20 
SEND_BIS RQ 3-67 
BIU 
See basic information unit (BIU) 
blanks 
See space (X'40') characters 
block chaining cryptography 6.2-6 
block diagram representation 1-1 
block diagram, arrow and line conventions 
within 1-6 
blocking of message units 
See reblocking 
BM 
See buffer manager (BM) 
bracket 2-15, 2-17, 2-33 
See also message unit (MU), session 
sequences 
bid 6.1-4, 6.1-10, 6.1-12, 6.1-16 


6.1-17 

bidding 6.1-5, 6.1-10 

bracket termination rule 6.1-4, 6.1-11 

error conditions 6.1-11 

first on session 2-33 

first speaker 6.1-4, 6.1-10, a 1-11 

Initiation 6.1-10 

protocols 6.1-1, 6.1-10 

relationship to conversation 6.1-10 

RH indicators 6.1-10, 6.1-12 

BRACKET_FREED structure A-18 

referenced by 
DFC_SEND_FROM_RM 6.1-21 
FREE_SESSION PROC 3-50 
GENERATE_RM_PS_INPUTS 6.1-36 
PROCESS PS TO_RM_RECORD 3-22 


bidder 6.1-4, 6.1-10, 6.1-11, 6.1-12, “~ 


BRACKET INITIATION STOPPED (BIS) 3-175 


5.3-12, 6.1-4,) 6.1-1l, 6.1-14, 6.1-15, 
6.1-16 
bracket state 2-32, 2-33, 2-34¢ 
bracket termination rule 


Cc 


’ 
vv 


See bracket, bracket termination rule ( 
buffer oe 


See also buffer manager (BM) 
pools B-2 
fixed dynamic B-2 


C : 
- 


\ 


limited B-2 
permanent B-2 
varying dynamic B-2 
types B-1, B-2 
demand B-2 
fixed dynamic B-2 
limited B-2 
link B-2 
permanent B-2 
varying dynamic B-2 
usage B-2, B-4 
buffer manager (BM) 2-35, 3-3, 4-31, 4-32; 
4-35, 4-36, 5.0-4, 5.1-1, 6.1-1>) B-1l 
See also buffer 
function B-1 
protocol boundary B-2,; B-5 
ADJUST_BUF_POOL B-6 
BUFFERS_RESERVED B-1l 
CREATE_BUF_POOL B-7 
DESTROY_BUF_POOL B-8 
FREE BUFFER B-9 
GET_BUFFER B-10 
protocol boundary with LU 2-46, 2-47 
sequence flows B-12 
Signals 6.2-7 
state 5.1-6 
buffer record 2-14, 2-15 
BUFFERS RESERVED 
See buffer manager (BM), protocol boundary 
BUFFERS_RESERVED_PROCESSING procedure 6.2-31 
referenced by 
PROCESS LU_LU SESSION 6.0-5 
BUILD_AND_SEND_ACT_SESS_RSP_NEG proce- 
dure 4-58 
referenced by 
FSM_STATUS 4-87 
PROCESS ACTIVATE_SESSION 4-75 
BUILD _AND_SEND_ACT_SESS_RSP_POS proce- 
dure 4-58 
referenced by 
FSM_STATUS 4-87 
BUILD_AND_SEND|BIND_RQ procedure 4-59 
referenced by 
PROCESS CINIT_SIGNAL 4-79 
BUILD _AND_SEND_BIND_RSP_NEG procedure 4-60 
referenced by 
PROCESS BIND_RQ 4-76 
BUILD _AND_SEND_FREE_LFSID procedure 4-60 
referenced by 
FSM_STATUS 4-87 
BUILD_AND_SEND_INIT_HS procedure 4-61 
referenced by 
PROCESS BIND RQ 4-76 
PROCESS _BIND_RSP 4-78 
BUILD_AND_SEND_INIT_SIG procedure 4-61 
referenced by 
FSM_STATUS 4-87 
BUILD_AND_SEND_PC_HS_DISCONNECT proce- 
dure 4-62 
referenced by 
FSM_STATUS 4-87 
BUILD_AND_SEND_SESS ACTIVATED procedure 4-63 
referenced by 
FSM_STATUS 4-87 
BUILD_AND_SEND_SESS_DEACTIVATED proce- 
dure 4-64 
referenced by 
FSM_STATUS 4-87 
BUILD _AND_SEND_SESSEND_SIG procedure 4-64 
referenced by 
CLEANUP_LU_LU SESSION 4-67 _. 
BUILD_AND_SEND_SESSST_SIG procedure 4-65 
referenced by 
FSM_STATUS 4-87 


BUILD_AND_SEND_UNBIND_RQ procedure 4-65 
referenced by 
FSM_STATUS 4-87 
PROCESS BIND RQ 4-76 
BUILD_AND_SEND_UNBIND_RSP procedure 4-66 
referenced by 
PROCESS _UNBIND_RQ 4-83 
BUILD_BIND_RSP_POS procedure 4-67 
referenced by 
PROCESS BIND_RQ 4-76 
BUILD_HS_TO_PS_HEADER procedure 6.1-28 
referenced by 
PROCESS RU DATA 6.1-40 


CALL statement 
finite-state machines N-1 
input signal N-1l 
next-state indicator N-1l 
cascaded agent 
See sync point, roles, cascaded agent 
cascaded protocol 
See sync point, roles, cascaded agent 
chain 2-15, 2-17 
relationship to verbs 2-18 
chaining 
definite-response chain 6.1-9 
exception-response chain 6.1-9 
general description 6.1-1, 6.1-9 
RH indicators 6.1-9 
use 1n FM profiles 6.1-4 
CHANGE_ACTION procedure 5.4-44 
referenced by 
LOCAL_SESSION_LIMIT_PROC 5.4-42 
PROCESS_SESSION_LIMIT_PROC 5.4-58 
RESET_SESSION_LIMIT_PROC 5.4-35 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
Change Direction indicator (CDI) 
use 6.1-5, 6.1-10, 6.1-11l, 6.1-12, 
6.1-13, 6.1-14, 6.1-16 
change number of sessions (CNOS) 2-36, 
5.4-3, 5.4-5 
See also presentation services for the 
control operator (PS.COPR) 
component relationship 5.4-6 
source-LU services 5.4-26 
_ target-LU services 5.4-29 
conversation 5.4-7 
allocating 5.4-28 
Attach processing 5.4-23 
basic conversation verbs used 5.4-9 
mode name 5.4-21, 5.4-28 
error recovery 
See error recovery, CNOS 
locking (LU,mode) entry 5.4-15, 5.4-31 
message unit flows 5.4-11 
privilege 5.4-25, 5.4-28 
processes 5.4-11 
concurrency 5.4-12 
race resolution 
action race 5.4-15 
command race 5.4-15 
double command failure 5.4-16, 5.4-20 
LU name comparison 5.4-21 
no race 5.4-17 
single command failure 5.4-17 
relationship to HS 5.4-12 
relationship to RM 5.4-8, 5.4-29 
relationship to SM 5.4-8 
retry 
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See change number of sessions (CNOS), 
race resolution, double command fail- 
ure 

See error recovery, CNOS 

security 
See change number of sessions (CNOS), 
privilege 
transaction 5.4-9, 5.4-13 
Change Number of Sessions GDS variable 5.4-7 
CNOS command 5.4-7, 5.4-28 
Close action 5.4-31 
Set action 5.4-29, 5.4-30 
CNOS reply 5.4-8, 5.4-28, 5.4-29 

See also Change Number of Sessions GDS 
variable, CNOS command 

Accepted reply modifier 5.4-29 

Command Race reply modifier 5.4-16, 
5.4-31 

Mode Name Closed reply modifi- 
er 5.4-30, 5.4-31 

Mode Name Not Recognized reply modi fi- 
er 5.4-31 

Negotiated reply modifier 5.4-29 

reply modifier field 5.4-31 

change-number-of-sessions service transaction 
program 5.4-1, 5.4-5, 5.4-12, 5.4-22, 
5.4-23 

name 5.4-23, 5.4-28 

relationship to PS.COPR 5.4-1, 5.4-29 
CHANGE_SESSION_LIMIT_PROC procedure 5.4-36 

referenced by 

PS_COPR 5.4-33 

CHANGE_SESSION_LIMIT verb 5. ag -6, 5.4-16, 
5.4-22 
processing by PS.COPR 5.4-30 
CHANGE_SESSIONS 5.4-8, 5.4-25, 5.4-26, 
5.4-29 
CHANGE_SESSIONS_PROC procedure 3-39 
referenced by 

PROCESS PS_TO_RM_RECORD 3-22 

CHANGE_SESSIONS structure A-15 
referenced by 

CHANGE_ACTION 5.4-44 

CHANGE_SESSIONS PROC 3-39 

PROCESS PS_TO_RM_RECORD 3-22 

CHECK_CNOS_COMMAND procedure 5.4-63 
referenced by 

~PROCESS SESSION_LIMIT_PROC 5.4-58 

CHECK_CNOS_REPLY procedure 5.4-56 
referenced by 

SOURCE_SESSION_LIMIT_PROC 5.4-4%6 

CHECK_FOR_BIS_REPLY procedure 3-40 
referenced by 

FSM_BIS BIDDER 3-87 
FSM_BIS FSP 3-88 

CINIT_SIGNAL 4-10 
CINIT_SIGNAL structure A-23 
referenced by 

FSM_STATUS 4-87 

PROCESS CINIT_SIGNAL 4-79 

PROCESS RECORD _FROM_SS 4-50 

class of service 2-3, 4-18 
CLEANUP_LU_LU_SESSION procedure 4-67 
referenced by 

FSM_STATUS 4-87 
PROCESS BIND_RQ 4-76 

CLOSE_ONE_REPLY procedure 5.4-65 
referenced by 

NEGOTIATE_REPLY 5.4-64 

CNOS 
See change number of sessions (CNOS) 
CNOS service TP 
See change-number-of-sessions service 
transaction program 
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commit 
See sync point 
commitment 
See sync point 
Committed 
See sync point, commands, Committed 
COMMON_CB structure 6. 0-8 
Compare States 
See sync point, commands, Compare States 
COMPLETE_CONFIRM_PROC procedure 5.1-28 
referenced by 
CONFIRM_PROC 5.1-12 
COMPLETE_DEALLOCATE_ABEND_PROC proce- 
dure 5.1-29 
referenced by 
DEALLOCATE_ABEND_PROC 5.1-31 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-646 
COMPLETE_LUW_ID procedure 3-41 
referenced by 
CREATE_TCB_AND_PS 3-45 
PS CREATION PROC 3-55 


( 


PS TERMINATION PROC 3-57 po 
conditional bracket termination \ 
See bracket, bracket termination rule ee 


Conditional End Bracket indicator (CEBTI ) 
use 6&.1-4, 6.1-5, 6.1-7, 6.1-10, 6.1-11,; 
6.1-13, 6.1-16 
CONFIRM_PROC procedure 5.1-12 
referenced by 
MC_CONFIRM_PROC 5.2-21 
-PS CONV 5.1-10 
CONFIRMED_PROC procedure 5.1-14 
referenced by 
MC_CONFIRMED_PROC 5.2-22 


PS CONV 5.1-10 
CONFIRMED structure A-10 ( * 
referenced by eee 
DFC_SEND_TO_PS 6.1-30 
RECEIVE _RM_OR_HS _TO_PS_RECORDS 5.1-51 
SEND_RSP_TO_RM_OR PS 6.1-46 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
conloser 
See contention loser 
CONNECT_RCB_AND_SCB procedure 3-42 
referenced by 
~ATTACH_PROC 3-30 
BID_RSP_PROC 3-35 


FIRST_SPEAKER_PROC 3-49 \ 
SESSION_ACTIVATED_ALLOCATION 3-70 C 
TEST_FOR_FREE_FSP_SESSION 3-82 \_ bf 


contention loser 2-8, 2-32, 5.4-3 

See also bidder 

See also bracket, bidder 

See also session, contention polarity 
contention winner 2-8, 2-32, 5.4-3 

See also bracket, first speaker 

See also first speaker 

See also session, contention polarity 
contention, bracket 

See bracket, protocols 
continuation bit in length prefix 2-13 

See also length prefix (LL) 
control mode 

immediate request 6.1-1, 6.1-4, 6.1-10 

immediate response 6.1-1, 6.1-4, 6.1-10 
control modes 

immediate request mode 6.2-7 

immediate response mode 6.2-7 
control operator 2-3, 2-36, 5.4-1, 5.4-23 a 

See also control-operator transaction pro- 

gram \ 
control-operator transaction program 2-3, 

2-34, 2-36, 2-43, 5.4-1, 5.4-5, 5.4-7, 
5.4-12, 5.4-21, 5.4-22, 5.4-23 


ms, a 


relationship to PS.COPR 5.4-1, 5.4-26 
control-operator verbs 2-3, 2-8) 2-36, 5.4-2 
CNOS 5.4-6, 5.4-22 
See also change number of sessions 
(CNOS ) 
distributed function 5.4-3, 5.4-5, 5.4-6 
local function 5.4-3, 5.4-5, 5.4-25 
local session control 5.4-5 
LU definition 5.4-5, 5.4-21 
processing by PS.COPR 5.4-25 
control point (CP), in T2.1 nodes 1-3, 1-5, 
2-4, 2-6, 2-8, 2-10, 2-17, 2-33 
relationship to LU 2-17, 2-27, 2-34; 
2-35, 2-46 
conversation 2-1, 2-3, 6.1-10 
See also bracket 
allocation to transaction program 2-32; 
3-5, 5.1-7 
basic 
See basic conversation 
deallocation 2-33 
mapped 
See mapped conversation 
relationship to bracket 6.1-10 
termination 3-13 
conversation correlator 5.3-3, 5.3-18 
conversation exchange 2-14 
See also message unit (MU), conversation 
sequences 
conversation failure 
See errors, conversation failure 
CONVERSATION_FAILURE_PROC procedure 5.1-29 
referenced by 
GET_END_CHAIN_FROM_HS 5.1-36 
RECEIVE_RM_OR_HS TO PS RECORDS 5.1-51 
WAIT _FOR_CONFIRMED_PROC 5.1-61 
WAIT_FOR_RM_REPLY 5.1-62 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-63 
CONVERSATION_FAILURE structure A-21 
referenced by 
CONVERSATION_FAILURE_PROC 5.1-29 
RECEIVE_RM_OR_HS TO_PS RECORDS 5.1-51 
SESSION_DEACTIVATED_PROC 3-72 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
WAIT_FOR_RM_REPLY 5.1-62 
WAIT_FOR_RSP_TO_RQ_TO_SEND_ PROC 5.1-63 
conversation-level security 2-9, 2-10, 2-32; 
2-33, 2-35, 3-2, 3-10 
access authorization list 2-10 
already verified Attach 2-10 
Already Verified indicator 2-10, 2-32 
downgrade 5.1-4, 5.1-7 
password 2-10, 2-35 
profile 2-10, 5.0-3 
user ID 2-10, 5.0-3 
conversation message 2-14, 2-15 
See also basic conversation message 
See also message unit (MU) 
conversation resource 2-32, 2-40 
See also conversation 
conwinner 
See contention winner 
CORRELATE_BIND_RSP procedure 4-68 
referenced by 
PROCESS BIND_RSP 4-78 
CORRELATE_UNBIND_RQ procedure 4-69 
referenced by 
PROCESS UNBIND_RQ 4-83 
correlation 
See request/response correlation 
correlation entries 


See request/response correlation 
CoS . 
See class of service 
cP 
See control point (CP), in T2.1 nodes 
CREATE_AND_INIT_LIMITED_MU procedure 5.1-30 
referenced by 
COMPLETE_CONFIRM_PROC 5.1-28 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-29 
CONFIRM_PROC 5.1-12 
DEALLOCATE_CONFIRM_PROC 5.1-32 
DEALLOCATE_FLUSH_PROC 5.1-33 
FLUSH_PROC 5.1-16 
OBTAIN SESSION PROC 5.1-37 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
PREPARE _TO_RECEIVE_FLUSH_PROC 5.1-42. 
RCB_ALLOCATED_PROC 5.1-48 
RECEIVE _AND_WAIT_PROC 5.1-19 
SEND_DATA_BUFFER_MANAGEMENT 5.1-54 
SEND_DATA_PROC 5.1-24 : 
CREATE_BUF_POOL 
See buffer manager (BM), protocol boundary 
CREATE_RCB procedure 3-43 
referenced by 
ALLOCATE_RCB_PROC 3-26 
TEST_FOR_FREE_FSP_SESSION 3-82 
CREATE_SCB procedure 3-44 
referenced by 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
CREATE_TCB_AND_PS procedure 3-45 
referenced by 
START_TP_PROC 3-77 
CRV 
See CRYPTOGRAPHY VERIFICATION (CRV) 
CRV_RQ_RU structure A-27 
referenced by 
TC.BUILD_CRV 6.2-17 
cryptography 6.2-1, 6.2-3, 6.2-%, 6.2-5; 
6.2-6 
See also session cryptography 
block chaining 6.2-6 
control modes 6.2-7 
CRV 6.2-3,5 6.2-4% 
initial chaining value 6.2-3, 6.2-4% 
session cryptography Key 6.2-3 
session seed 6.2-3 
test value 6.2-3 
Data Encryption Standard (DES) 6.2-7 
initial chaining value 6.2-3, 6.2-4¢ 
initialization 6.2-3 
parameters in BIND 4-22 
session cryptography Key 6.2-3, 6.2-7 
session Key distribution 6.2-5 
session-level cryptography 4-22, 6.2-1 
session seed 6.2-3» 6.2-6 
session seed distribution 6.2-5 
CRYPTOGRAPHY VERIFICATION (CRV) 6.2-3 
session cryptography Key 6.2-3 
session seed 6.2-3 
test value 6.2-3 
CT structure 6.0-8 
referenced by 
CT_UPDATE 6.1-29 
CT_UPDATE procedure 6.1-29 
referenced by 
DFC_RCV_FSMS 6.1-25 
DFC_SEND_FSMS 6.1-27 
current bracket ID 
See current bracket sequence number 
current bracket sequence number 6.1-5, 
6.1-7, 6.1-8 
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data-base resources 2-4, 2-37 
consistency of updates 
See sync point, data-base update con- 
sistency 
Data Encryption Standard (DES) 
data flow control (DFC) : 
BIS  6.1-4G> 6.1-l1l> 6.1-14;5 6.1-15, 6.1-16 
initialization 6.1-1 
LUSTAT 6.1-4, 6.1-5, 6.1-11, 6.1-14> 
6.1-15, 6.1-16 
protocol boundaries 6.1-3 — 
request formats 6.1-14, 6.1-15 
response formats 
RTR 6.1-4, 6.1-5, 6.1-8, 6.1-10, 6.1-l1l; 
6.1-14, 6.1-15, 6.1-17 
SIG 6.1-4, 6.1-5, 6.1-7,) 6.1-8, 6.1-14), 
6.1-15, 6.1-17 
structure 6.1-1 
data record 2-13, 2-30, 2-36 
data structures 2-40 
system definition 2-40 
data traffic 
activation 6.2-1 
deactivation 6.2-1 
data traffic protocols 
CRV 6.2-3 
session cryptography key 6.2-3 
session seed 6.2-3 
test value 6.2-3 
session cryptography key 6.2-3 
session seed 6.2-3 
DEACTIVATE_FREE_SESSIONS procedure 3-46 
referenced by 
CHANGE_SESSIONS PROC 3-39 
DEACTIVATE_PENDING_ SESSIONS procedure 3-47 
referenced by 
CHANGE_SESSIONS_ PROC 3-39 
DEACTIVATE_SESSION 4-5 
DEACTIVATE_SESSION_PROC procedure 5.4-38 
referenced by 
PS_COPR 5.4-33 
DEACTIVATE_SESSION structure A-21 
referenced by 
FSM_STATUS 4-87 
PROCESS _DEACTIVATE_SESSION 4-80 
PROCESS RECORD_FROM_RM 4-49 
PS _ABEND_PROC 3-54 
PURGE_QUEUED_ REQUESTS 3-59 
SEND_DEACTIVATE_SESSION 3-68 
DEACTIVATE_SESSION verb 5.4-6, 5.4-21, 
5.4-26 
deactivation, session 
LU-LU 4-2 
deadlock 6.2-8 
DEALLOCATE_ABEND_PROC procedure 5.1-31 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_CONFIRM_PROC procedure 5.1-32 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_FLUSH_ PROC procedure 5.1-33 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_PROC procedure 5.1-15 
referenced by 
MC_DEALLOCATE_PROC 5.2-23 
PROTOCOL_ERROR_PROC 5.2-47 
PS CONV 5.1-10 
DEALLOCATE_RCB structure A-16 
referenced by 
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END_CONVERSATION_PROC 5.1-34¢ 
PROCESS PS _TO_RM_RECORD 3-22 
DEALLOCATION_CLEANUP_PROC procedure 5.0-18 
referenced by 
PS 5.0-8 
deciphering 6.2-1, 6.2-6 
block chaining 6.2-6 
CRV 6.2-3 
See also data traffic protocols 
session cryptography Key 6.2-3 
session seed 6.2-3 
test value 6.2-3 
Data Encryption Standard (DES) 6.2-7 
session cryptography Key 6.2-3, 6.2-7 
session seed 6.2-3 
DEFINE_PROC procedure 5.4-39 
referenced by 
PS COPR 5.4-33 
definite-response chain 
See chaining,» definite-response chain 
DELETE_PROC procedure 5.4-41 
referenced by 
PS _COPR 5.4-33 
demand buffers 
See buffer, types 
DEQUEUE_FMH7_PROC procedure 5.1-34 
referenced by 
CONFIRM_PROC 5.1-12 
DEALLOCATE_CONFIRM_PROC 5.1-32 
PREPARE_TO_RECEIVE CONFIRM_PROC 5.1-41 
RECEIVE _AND_WAIT_PROC 5.1-19 
RECEIVE IMMEDIATE PROC 5.1-21 
SEND_DATA_PROC 5.1-24 
SEND_ERRCR_IN_SEND STATE 5.1-57 
TEST_PROC 5.1-26 
WAIT FOR_CONFIRMED_ PROC 5.1-61 
DEQUEVUE_WAITING_REQUEST procedure 3-48 
referenced by 
FREE SESSION PROC 3-50 
RTR_RSP_PROC 3-64 
DES algorithm 4-18 
destination transaction program 2-7 
DESTROY_BUF_POOL 
See buffer manager (BM), protocol boundary 
DFC_INITIALIZE procedure 6.1-19 
referenced by 
HS 6.0-3 
DFC_RCV_FSMS procedure 6.1-25 
referenced by 
DFC_RCV 6.1-24 
DFC_RCV procedure 6.1-24¢ 
referenced by 
TC.RCV 6.2-23 
DFC_SEND_FROM_PS procedure 6.1-20 
referenced by 
PROCESS _LU_LU_ SESSION 6.0-5 
DFC_SEND_FROM_RM procedure 6.1-21 
referenced by 
PROCESS LU_LU_SESSION 6.0-5 
DFC_SEND_FSMS procedure 6.1-27 
referenced by 
DFC_SEND_FROM PS 6.1-20 
DFC_SEND_FROM RM 6.1-21 
SEND_FMD_MU 6.1-43 
SEND_RSP_MU 6.1-45 
DFC_SEND_TO_PS procedure 6.1-30 
referenced by 
GENERATE_RM_PS_ INPUTS 6.1-36 
PROCESS RU_DATA 6.1-40 
SEND_RSP_TO_RM_OR_PS 6.1-46 
TRY_TO_RCV_SIGNAL 6.1-23 
DIA 
See Document Interchange Architecture 
(DIA) 


C 


—_ 


a 
oo, 


N 
/ 
C- 


Co | 
ff 


DISPLAY_PROC procedure 5.4-40 
referenced by 
PS COPR 5.4-33 
distributed operator control 2-3 
See also control-operator verbs, distrib- 
uted function 
distributed processing 2-1 
distributed transaction 2-1, 2-36, 2-43 
CNOS 5.4-9 
distributed transaction program 
See logical unit of work (LUW), distrib- 
uted 
distribution service unit (DSU) 2-36 
Document Interchange Architecture (DIA) 2-36 
domain, definition of 1-5 
drain 2-34) 2-43 
drain of session allocation requests 3-17, 
5.4-4, 5.4-8, 5.4-22, 5.4-26,) 5.4-31 
negotiation by CNOS 5.4-31 
DSU 
See distribution service unit (DSU) 


[= | 


EDI 
See Enciphered Data indicator (EDI) 
enciphered data 4-26 
See also LU-LU verification 
See also session-level security, enci- 
phered data 
Enciphered Data indicator (EDI) 6.2-6 
ENCIPHERED_RD2 structure A-18 
referenced by 
DFC_SEND_FROM_RM 6.1-21 
SUCCESSFUL_SESSION_ACTIVATION 3-81 
enciphering 6.2-1, 6.2-6 
block chaining 6.2-6 
CRV 6.2-3 
See also ‘data traffic protocols 
session seed 6.2-3 
test value 6.2-3 
Data Encryption Standard (DES) 6.2-7 
session cryptography Key 6.2-3, 6.2-7 
session seed 6.2-3 
End Chain indicator (ECI) 
use 6.1-9, 6.1-13 
END_CONVERSATION_PROC procedure 5.1-34 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
DEALLOCATE_ABEND_PROC 5.1-31 
DEALLOCATE_FLUSH_PROC 5.1-33 
DEALLOCATE_PROC 5.1-15 
FLUSH_PROC 5.1-16 
WAIT _FOR_CONFIRMED_PROC 5.1-61 
end-of-chain type 5.1-7 
end-of-conversation message 2-14, 2-19), 
2-30, 2-31 
ERROR_DATA_STRUCTURE structure 5.2-48 
referenced by 
PROCESS _ERROR_DATA 5.2-4%3 
RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
SEND_SVC_ERROR_PURGING 5.2-45 
Error Description FM header (FMH-7) 
See FM header, type 7 (Error Description) 
error recovery 
See also errors 
CNOS 5.4-28, 5.4-31 
conversation failure 5.4-21, 5.4-28 
protocol violation 5.4-31 
unrecognized command parameters 5.4-31 


confirmation 2-11, 2-14 

control operator 2-12 

conversation deallocation 2-11 

distributed 

See sync point 

LU 2-12 

program 2-11, 2-14 

session deactivation 2-12 

sync point 

See sync point 

transaction program 2-11 
errors 2-10 

See also error recovery 

See also errors and failures 

application-detected 2-10 

conversation failure 2-11, 2-34, 5.1-9 

local resource 2-10 

LU failure 2-11, 2-38 

Program failure 2-11 

protocol 5.1-9 

session failure 2-11 

system recoverable 2-11 
errors and failures 5.3-1, 5.3-19, 5.3-24, 
5.3-25, 5.3-30, 5.3-31, 5.3-32,) 5.3-33,5 
5.3-41 

application errors 5.3-1 

conversation failures 5.3-1, 5.3-2;5 

§.3-18, 5.3-19, 5.3-22, 5.3-32 

local resource failures 5.3-1 

LU failures 5.3-1, 5.3-2, 5.3-20 

program failures 5.3-1, 5.3-2 

recoverable system errors 5.3-1 
errors during sync point 

See sync point, errors during sync point 
exception-response chain 

See chaining, exception-response chain 
Exchange Log Name 

See sync point, commands, Exchange Log 

Name 
expedited flow 

in contrast to normal flow 6.2-6, 6.2-7 

TC 6.2-1, 6.2-6) 6.2-7 


failures 
See errors and failures 
files 
See sync point, local resources 
finite-state machine (FSM), basic notion 
of l-l 
finite-state machines N-1 
call N-1 
generic finite-state machines N-1l 
initialization N-1 
no-op finite-state machines N-1l 
state N-1 
state check N-1 
state name N-1 
state test N-1l 
state transition N-1 
first speaker 2-8, 2-32 
See also bracket, first speaker 
See also contention winner 
FIRST_SPEAKER_PROC procedure 3-49 
referenced by 
GET_SESSION_PROC 3-52 
fixed dynamic buffer pool 
See buffer, pools 
fixed dynamic buffers 
See buffer, types 
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fixed pacing " 
See session-level pacing FREE_SESSION_PROC 3-50 _ 
flip-flop, half-duplex FSM CHAIN RCV_FMP19 6.1-51 Nee 
See send/receive mode, half-duplex FSM_CHAIN_SEND_FMP19 6.1-53 . 
flip-flop (HDX-FF) PROCESS HS _TO_RM_RECORD 3-20 
flow control messages FSM_BIS_ BIDDER 3-87 
adaptive pacing responses 6.2-8 FSM_BIS_ BIDDER FSM 
reset acknowledgments 6.2-8 referenced by 
solicited IPMs 6.2-8 BID_PROC 3-33 
unsolicited IPMs 6.2-8 CREATE_SCB 3-44 
pacing requests 6.2-8 FREE_SESSION_PROC 3-50 
flow sequences 4-30 PROCESS_HS_TO_RM_RECORD 3-20 
FLUSH_PROC procedure 5.1-16 RM_DEACTIVATE_SESSION_PROC 3-62 
referenced by RTR_RSP_PROC 3-64 
MC_FLUSH_PROC 5.2-23 SEND_BIS 3-66 
PS CONV 5.1-10 | SEND BIS_REPLY 3-67 
FM header 2-14, 2-15, 2-17, 2-38 SEND_BIS_RQ 3-67 
relationship to verbs 2-18 SHOULD_SEND_BIS 3-76 
type 12 (Security) 2-10, 2-14, 2-33, FSM_BIS_FSP 3-88 
2-35, 3-15, 6.1-4 FSM_BIS_FSP FSM 
type 5 (Attach) 2-10, 2-14, 2-31, 2-32, referenced by 
3-2, 3-10, 5.0-Gy 5.1-7> 5.3-12) 6.1-4 BID PROC 3-33 ro 
type 7 (Error Description) 2-14, 5.1-7, CREATE_SCB 3-44 \ 
5.3-6, 5.3-7, 6.1-4, 6.1-8 FREE _SESSION_PROC 3-50 co 
use in FM profile 19 6.1-4 PROCESS_HS_TO_RM_RECORD 3-20 
FM profile RM_DEACTIVATE_SESSION_PROC 3-62 
See also profiles RTR_RSP_PROC 3-64 
in BIND 4-20 SEND_BIS 3-66 
FM profile 0 6.1-1 SEND_BIS REPLY 3-67 
FM profile 19 6.1-1, 6.1-4, 6.1-9, 6.1-16 SEND_BIS_ RQ 3-67 
FM profile 6 6.1-1 SHOULD_SEND_BIS 3-76 
FM Usage field FSM_BSM_FMP19 6.1-50 
in BIND 4-20 FSM_BSM_FMP19 FSM 
FMH-12 referenced by 
See FM header, type 12 (Security) DFC_INITIALIZE 6.1-19 : 
FMH-5 DFC_SEND_FROM_RM 6.1-21 
See FM header, type 5 (Attach) FSM_CHAIN_RCV_FMP19 6.1-51 © 
FMH-7 : FSM_CHAIN_SEND_FMP19 6.1-53 
See FM header, type 7 (Error Description) PROCESS _LU_LU_SESSION 6.0-5 
FORCE parameter PROCESS RU_DATA 6.1-40 
See RESET_SESSION LIMIT verb, processing RCV_STATE_ERROR 6.1-41 
by PS.COPR, FORCE parameter REPLY TO. BID 6.1-42 
Forget SEND_BID_POS_RSP 6.1-42 
See sync point, commands, Forget SEND_RSP_TO_RM_OR_PS 6.1-46 
formal description, definition of 1-1 STRAY_RSP 6.1-48 
FORMAT_ERROR_EXP_RSP procedure 6.1-32 TRY_TO_RCV_SIGNAL 6.1-23 
referenced by FSM_CHAIN_RCV_FMP19 6.1-51 
FORMAT_ERROR 6.1-31 FSM_CHAIN_RCV_FMP19 FSM a 
FORMAT_ERROR_NORM_RSP procedure 6.1-32 referenced by \ 
referenced by DFC_INITIALIZE 6.1-19 eee 
FORMAT_ERROR 6.1-31 DFC_RCV_FSMS 6.1-25 
FORMAT_ERROR procedure 6.1-31 DFC_SEND_FROM PS 6.1-20 
referenced by DFC_SEND_FSMS 6.1-27 
DFC_RCV 6.1-24¢ OK_TO_REPLY 6.1-39 
FORMAT_ERROR_RQ_DFC procedure 6.1-33 RCV_STATE_ERROR 6.1-41 
referenced by SEND_RSP_IF_REQUIRED 6.1-44 
FORMAT_ERROR 6.1-31 . SEND_RSP_MU 6.1-45 
FORMAT_ERROR_RQ_FMD procedure 6.1-34 FSM_CHAIN_SEND_FMP19 6.1-53 
referenced by FSM_CHAIN_SEND_FMP19 FSM 
FORMAT_ERROR 6.1-31 referenced by 
FORMAT_ERROR_RQ DFC 6.1-33 DFC_INITIALIZE 6.1-19 
Format indicator (FI) DFC_RCV_FSMS 6.1-25 
use 6.1-4 DFC_SEND_FSMS 6.1-27 
FREE BUFFER OK_TO_REPLY 6.1-39 
See buffer manager (BM), protocol boundary PROCESS_LU_LU_SESSION 6.0-5 
FREE_LFSID 4-12 RCV_STATE_ERROR 6.1-41 
FREE_LFSID structure A-25 FSM_CONVERSATION 5.1-65 
referenced by FSM_CONVERSATION FSM 
BUILD_AND SEND_FREE_LFSID 4-60 referenced by a 


free-session pool 3-12 
FREE_SESSION_PROC procedure 3-50 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-20 
FREE_SESSION structure A-12 
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referenced by 


COMPLETE_CONFIRM_PROC 5.1-28 
CONFIRM_PROC 5.1-12 
CONFIRMED_PROC 5.1-14 
DEALLOCATE_ABEND_PROC 5.1-31 
DEALLOCATE_CONFIRM_PROC 5.1-32 


\ 
Ne 


DEALLOCATE_FLUSH_PROC 5.1-33 RCV_STATE_ERROR 6.1-41 


DEALLOCATE_PROC 5.1-15 FSM_RCB_STATUS_BIDDER 3-89 
DEALLOCATION_CLEANUP_PROC 5.0-18 FSM_RCB_STATUS_BIDDER FSM 
DEQUEUE_FMH7_PROC 5.1-34 referenced by 
FLUSH_PROC 5.1-16 BID_RSP_PROC 3-35 
GET_ATTRIBUTES PROC 5.1-17 BIDDER_PROC 3-37 
GET_DEALLOCATE_FROM_HS 5.1-35 CREATE_RCB 3-43 
GET_END_CHAIN FROM_HS 5.1-36 FREE_SESSION PROC 3-50 
PERFORM_RECEIVE_EC_ PROCESSING 5.1-38 PS_ABEND_PROC 3-54 
PERFORM_RECEIVE PROCESSING 5.1-40 PS _CREATION_PROC 3-55 
POST_ON_RECEIPT_PROC 5.1-17 QUEUE_ATTACH_PROC 3-60 
PREPARE _TO_RECEIVE CONFIRM_PROC 5.1-41 SESSION_ACTIVATED_ALLOCATION 3-70 
PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-42 SESSION_DEACTIVATED_PROC 3-72 
PREPARE _TO RECEIVE PROC 5.1-18 SET_RCB_AND_SCB_FIELDS 3-75 
PROCESS _FMH7_PROC 5.1-46 FSM_RCB_STATUS_FSP 3-90 
RCB_ALLOCATED_PROC 5.1-48 FSM_RCB_STATUS_FSP FSM 
RECEIVE _AND_WAIT_PROC 5.1-19 referenced by 
RECEIVE IMMEDIATE PROC 5.1-21 BID_RSP_PROC 3-35 
RECEIVE_RM_OR_HS _TO_PS RECORDS 5.1-51 BIDDER_PROC 3-37 
REQUEST_TO_SEND_PROC 5.1-23 CREATE_RCB 3-43 
SEND_DATA_PROC 5.1-24 FREE_SESSION PROC 3-50 
SEND_ERROR_DONE_PROC 5.1-55 PS_ABEND_PROC 3-54 
SEND_ERROR_IN_RECEIVE_STATE 5.1-56 PS CREATION PROC 3-55 
SEND_ERROR_IN_SEND_STATE 5.1-57 QUEUE_ATTACH_PROC 3-60 
SEND_ERROR_PROC 5.1-25 SESSION_ACTIVATED_ALLOCATION 3-70 
SET_FMH7_RC 5.1-59 SESSION_DEACTIVATED_PROC 3-72 
TEST PROC 5.1-26 SET_RCB_AND_SCB_ FIELDS 3-75 
WAIT _FOR_CONFIRMED PROC 5.1-61 FSM_RCV_PURGE_FMP19 6.1-56 
WAIT_FOR_RSP_TO_RQ TO_SEND PROC 5.1-63 FSM_RCV_PURGE_FMP19 FSM 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-64 referenced by 
FSM_ERROR_OR_FAILURE 5.1-67 DFC_INITIALIZE 6.1-19 
FSM_ERROR_OR_FAILURE FSM DFC_RCV_FSMS 6.1-25 
referenced by GENERATE_RM_PS_INPUTS 6.1-36 
CONFIRM_PROC 5.1-12 FSM_SCB_STATUS_BIDDER 3-85 
CONFIRMED PROC 5.1-14¢ FSM_SCB_STATUS_BIDDER FSM 
CONVERSATION_FAILURE_PROC 5.1-29 referenced by 
DEALLOCATE_ABEND_PROC 5.1-31 ATTACH_PROC 3-30 
DEALLOCATE_CONFIRM_PROC 5.1-32 BID_PROC 3-33 
DEALLOCATE_FLUSH_PROC 5.1-33 CREATE _SCB 3-44 
FLUSH_PROC 5.1-16 FREE_SESSION_PROC 3-50 
FSM_CONVERSATION 5.1-65 PS ABEND PROC 3-54 
GET_DEALLOCATE_FROM_HS 5.1-35 QUEUE_ATTACH_PROC 3-60 
PERFORM_RECEIVE PROCESSING 5.1-40 SECURITY_PROC 3-65 
PREPARE _TO_RECEIVE CONFIRM_PROC 5.1-41 SESSION_DEACTIVATED_PROC 3-72 
PREPARE_TO RECEIVE FLUSH PROC 5.1-42 SET_RCB_AND SCB_ FIELDS 3-75 
PROCESS_FMH7_LOG_DATA_PROC 5.1-44¢ SUCCESSFUL_SESSION_ACTIVATION 3-80 
PROCESS_FMH7_PROC 5.1-46 FSM_SCB_STATUS_FSP 3-86 
RECEIVE AND_WAIT_PROC 5.1-19 FSM_SCB_STATUS_FSP FSM 
RECEIVE _IMMEDIATE_PROC 5.1-21 referenced by 
RECEIVE_RM_OR_HS TO_PS RECORDS 5.1-51 ATTACH PROC 3-30 
REQUEST _TO SEND PROC 5.1-23 BID PROC 3-33 
SEND_DATA_PROC 5.1-24¢ CREATE_SCB 3-44 
SEND_ERROR_IN_SEND_STATE 5.1-57 FREE _SESSION_PROC 3-50 
SEND_ERROR_PROC 5.1-25 PS ABEND_PROC 3-54 
SET_FMH7_RC 5.1-59 QUEUE_ATTACH_PROC 3-60 
TEST_PROC 5.1~-26 SECURITY_PROC 3-65 
WAIT_FOR_CONFIRMED_PROC 5.1-61 SESSION_DEACTIVATED_PROC 3-72 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-63 SET_RCB_AND_SCB_FIELDS 3-75 
WAIT_FOR_SEND_ERROR_DONE PROC 5.1-64 SUCCESSFUL_SESSION_ACTIVATION 3-80 
FSM_POST 5.1-68 FSM_STATUS 4-86 
FSM_POST FSM | FSM_STATUS FSM 
referenced by referenced by 
CONVERSATION_FAILURE_PROC 5.1-29 PROCESS ABEND_NOTIFICATION 4-74 
DEQUEUE_FMH7_PROC 5.1-34 PROCESS ABORT_HS 4-74 
POST_ON_RECEIPT_ PROC 5.1-17 PROCESS ACTIVATE_SESSION 4-75 
RECEIVE AND TEST POSTING 5.1-50 PROCESS BIND_RQ 4-76 
RECEIVE IMMEDIATE PROC 5.1-21 PROCESS BIND_RSP 4-78 
TEST_FOR_POST_SATISFIED 5.1-60 PROCESS CINIT_SIGNAL 4-79 
TEST_PROC 5.1-26 PROCESS DEACTIVATE_SESSION 4-80 
FSM_QRI_CHAIN_RCV_FMP19 6.1-55 PROCESS_INIT_HS_RSP 4-81 
FSM_QRI_CHAIN_RCV_FMP19 FSM PROCESS_INIT_SIGNAL_NEG_RSP 4-81 
referenced by PROCESS SESSION _ROUTE_INOP 4-83 
DFC_INITIALIZE 6.1-19 PROCESS _UNBIND_RQ 4-83 
DFC_RCV_FSMS 6.1-25 | full-duplex send/receive mode 


Index Xx-9 


See send/receive mode, full-duplex (FDX) 


fully qualified LU name 

See LU name, network-qualified 
function shipping 

See sync point, function shipping 


Le | 


GDS header 
See general data stream header 
GDS ID 


See general data stream variable identifi- 


er 
GDS variable 
See general data stream variable 


general data stream header 2-13, 2-30, 2-31 


general data stream variable 2-13, 2-36, 
5.2-5 
Application Data 5.2-5, 5.2-11 
Change Number of Sessions 2-36 


See also Change Number of Sessions GDS 


variable 
Compare States 2-40 
Error Data 5.2-14, 5.2-15 
Exchange Log Name 2-40 
Map Name 2-37, 5.2-9, 5.2-11 
Null Data 5.2-5 


User Control Data 5.2-5, 5.2-11, 5.2-14¢ 


general data stream variable identifier 
general data stream variables 
for mapped conversations 2-15, 2-37 
for resynchronization 2-40 
GENERATE_RM_PS_INPUTS procedure 6.1-36 
referenced by 
DFC_RCV_FSMS 6.1-25 
generic finite-state machines N-1 
initialization N-1 
no-op finite-state machines N-1 
GET_ATTRIBUTES_PROC procedure 5.1-17 
referenced by 
MC_GET_ATTRIBUTES PROC 5.2-24 
PS CONV 5.1-10 
GET_BUFFER 


See buffer manager (BM), protocol boundary 


GET_DEALLOCATE_FROM_HS procedure 5.1-35 
referenced by 
PROCESS _FMH7_LOG_DATA_PROC 5.1-44. 
PROCESS _FMH7_PROC 5.1-46 
GET_END_CHAIN_FROM_HS procedure 5.1-36 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
GET_DEALLOCATE_FROM_HS 5.1-35 


WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-64¢ 


GET_FQPCID procedure 4-70 
referenced by 
INITIALIZE_LULU_CB_ BIND 4-71 
PROCESS_ACTIVATE_SESSION 4-75 
GET_SEND_INDICATOR procedure 5.2-44 
referenced by 
RCVD_SVC_ERROR_PURGING 5.2-42 
GET_SESSION_PROC procedure 3-52 
referenced by 
BID_RSP_PROC 3-35 
DEQUEUE_WAITING_REQUEST 3-48 
PROCESS PS_TO_RM_RECORD 3-22 
RTR_RQ PROC 3-63 
SESSION_DEACTIVATED._ PROC 3-72 
GET_SESSION structure A-16 
referenced by 
BID_RSP_PROC 3-35 
BIDDER_PROC 3-37 
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CHECK_FOR_BIS_REPLY 3-40 

DEQUEUE_ WAITING _REQUEST 3-48 

FIRST_SPEAKER_PROC 3-49 

FREE SESSION PROC 3-50 

GET_SESSION_PROC 3-52 

OBTAIN_SESSION_PROC 5.1-37 

PROCESS PS TO_RM_RECORD 3-22 

PS ABEND PROC 3-54 

RTR_RQ PROC 3-63 

SEND_DEACTIVATE_SESSION 3-68 

SESSION_ACTIVATED_ALLOCATION 3-70 

SESSION _DEACTIVATED_PROC 3-72 

SUCCESSFUL_SESSION_ACTIVATION 3-81 

UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
GET_TP_PROPERTIES PROC procedure 5.0-18 

referenced by 
PS_VERB_ROUTER 5.0-16 


iG o 


half-duplex flip-flop send/receive mode 2-6 

See also send/receive mode, half-duplex 
flip-flop (HDX-FF) 

See also two-way alternate send/receive 
protocol 

half-session (HS) 2-1 
activation and deactivation 6.0-1 
components 6.0-1 
function summary 2-35 
process 2-32, 2-34) 2-40, 2-44 


CHANGE_SESSIONS PROC 3-39 e 


ee 


process queues 6.0-1 GX 
processes 6.0-1 ( | 
protocol boundaries 2-46, 2-47, 6.0-2 Neca 


half-session ID 2-6 
HS 
See half-session (HS) 
HS _CREATE_PARMS structure A-26 
referenced by 
HS 6.0-3 
HS_ID structure 3-91 
referenced by 
BIDDER_PROC 3-37 
BIS _RACE_LOSER 3-38 
CHECK_FOR_BIS_REPLY 3-40 a 
CONNECT_RCB_AND_SCB 3-42 C 
DEQUEUE WAITING REQUEST 3-48 
FIRST_SPEAKER_PROC 3-49 
FSM_BIS BIDDER 3-87 
FSM_BIS FSP 3-88 
PS_PROTOCOL_ERROR 5.0-20 
SEND_BIS 3-66 
SEND BIS_REPLY 3-67 
SEND BIS _RQ 3-67 
SESSION_ACTIVATED_ALLOCATION 3-70 
SET_RCB_AND_SCB_FIELDS 3-75 
SHOULD SEND BIS 3-76 
HS process 6.0-3 : 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
BID_PROC 3-33 
BID_RSP_PROC 3-35 
BIDDER_PROC 3-37 
BIS_RACE_LOSER 3-38 
BUILD_AND_SEND_INIT_HS 4-61 


COMPLETE_CONFIRM_PROC 5.1-28 My 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-29 C 
CONFIRM_PROC 5.1-12 soe 


CONNECT_RCB_AND_SCB 3-42 
DEALLOCATE_CONFIRM_PROC 5.1-32 
DEALLOCATE_FLUSH_PROC 5.1-33 


mm, 
‘ 
\ 
| 
? 
we 


DFC_INITIALIZE 6.1-19 
DFC_SEND_FROM_PS 6.1-20 
DFC_SEND TOPS 6.1-30 

END CONVERSATION PROC 5.1-34 
FLUSH_PROC 5.1-16 

FREE SESSION PROC 3-50 
FSM_CONVERSATION 5.1-65 
INVALID_SENSE_CODE 6.1-38 


PREPARE_TO_RECEIVE:. CONFIRM_PROC 5.1-41 


PREPARE_TO_RECEIVE_FLUSH_PROC 
PROCESS_HS_TO_RM_RECORD 3-20 
PROCESS PS _TO_RM_RECORD 3-22 
PS TERMINATION PROC 3-57 
RCB_ALLOCATED_PROC 5.1-48 
RECEIVE_AND_WAIT_PROC 5.1-19 
RTR_RQ_PROC 3-63 
SEGMENT_REASSEMBLY 6.2-28 
SEND_BIS_ REPLY 3-67 

SEND BIS RQ 3-67 

SEND _CONFIRMED_PROC 5.1-53 


5.1-42 


SEND_DATA_BUFFER_MANAGEMENT 5.1-54 


SEND_DATA_PROC 5.1-24 
SEND_ERROR_DONE_PROC 5.1-55 


SEND_ERROR_IN_SEND_STATE 5.1- 


SEND_ERROR_TO_HS PROC 5.1-58 


57 


SEND _REQUEST_TO_SEND_PROC 5.1-58 


SUCCESSFUL_SESSION_ACTIVATION 
TC.BIU_RCV_CHECKS 6.2-25 
TC.BUILD_CRV 6.2-17 
TC.CRV_FORMAT_CHECK 6.2-18 
TC.DECIPHER_RU 6.2-32 
TC.EXCHANGE_CRV 6.2-15 
TC.INITIALIZE 6.2-13 
TC.RCV 6.2-23 
TC.SEGMENT_RCV_CHECKS 6.2-24¢ 
HS _PS_CONNECTED structure A-18 
referenced by 
CONNECT_RCB_AND_SCB 3-42 
DFC_SEND_FROM_RM 6.1-21 
PROCESS RU_DATA 6.1-40 
PS _TERMINATION_PROC 3-57 
SEND BID: POS RSP 6.1-42 


identification of session 

in BIND 4-23 
immediate request mode 6.1-10 

See also control mode, immediate 
immediate response mode 6.1-10 

See also control mode, immediate 
implementation-dependent parameters 
implementation-determined functions 

See also non-SNA functions 

API 2-4 

closed 2-12 

control operator 2-3 

control operator TP 2-36 

error recovery 2-11 

logging 2-38 

mapping 2-36 

names 2-5 

network configuration 2-4 

optional function sets 2-12 

record length and format con- 

straints 2-13, 2-30 

resources 2-29, 2-38 

system. definition 2-43 
implied Forget 


3-80 


request 


response 
4-18 


See sync point, commands, implied Forget 


INIT_HS 4-7 


INIT_HS_RSP 4-7 
INIT_HS_RSP structure A-10 
referenced by 
FSM_STATUS 4-87 
HS 6.0-3 
PROCESS_INIT_HS_RSP 4-81 
PROCESS RECORD_FROM_HS 4-50 
INIT_HS structure A-13 
referenced by 
BUILD_AND_SEND_INIT_HS 4-61 
DFC_INITIALIZE 6.1-19 
HS 6.0-3 
TC.BUILD_CRV 6.2-17 
TC .EXCHANGE CRV 6.2-15 
TC.INITIALIZE 6.2-13 
INIT_SIGNAL 4-9 
INIT_SIGNAL_NEG_RSP 4-10 
INIT_SIGNAL_NEG_RSP structure A-23 
referenced by 
FSM_STATUS 4-87 
PROCESS _INIT_SIGNAL_NEG_RSP 4-81 
PROCESS RECORD_FROM_SS 4-50 
INIT_SIGNAL structure A-23 
referenced by 
BUILD_AND_SEND_INIT SIG 4-61 
PROCESS CINIT_SIGNAL 4-79 
PROCESS _INIT_SIGNAL_NEG_RSP 4-81 
initial chaining value 6.2-3, 6.2-4 
initialization 
See transmission control 
initialization of generic finite-state 
machines N-1 


INITIALIZE_ATTACHED_RCB procedure 5.0-20 


referenced by 
PROCESS _FMH5 5.0-10 


INITIALIZE_LULU_CB_ACT_SESS procedure 4-70 


referenced by 
PROCESS _ACTIVATE_SESSION 4-75 
INITIALIZE_LULU_CB_BIND procedure 4-71 
referenced by 
PROCESS_BIND_RQ 4-76 
INITIALIZE SESSION _LIMIT_PROC proce- 
dure 5.4-34 
referenced by 
PS COPR 5.4-33 


INITIALIZE_SESSION_LIMIT verb 5.4-6, 5.4-22 


processing by PS.COPR 
parallel-session mode name 5.4-30 
single-session mode name 5.4-25 
SNASVCMG mode name 5.4-25 
INITIALIZE _TH_RH procedure 6.1-38 
referenced by 
DFC_SEND_ FROM PS 6.1-20 
DFC_SEND_ FROM RM 6.1-21 
SEND_FMD_MU 6.1-43 
SEND_RSP_MU 6.1-45 
initiating process (IP) 2-36, 3-3, 3-5 
protocol boundary 2-47 
SEND_RTR 3-5 
START_TP 3-5 
initiator 
See sync point, roles, initiator 
installation-specified parameters 4-18 
instance limit 2-5 
See also transaction program instance 
(TP), Limit 
intermediate routing 1-4 
INVALID_SENSE_CODE procedure 6.1-38 
referenced by 
RCV_STATE_ERROR 6.1-41 
IPM | 
See ISOLATED PACING MESSAGE (IPM) 
IPM_RU structure 6.2-33 
referenced by 


Index 
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BUFFERS_RESERVED_PROCESSING 6.2-31 
MU_PACING CHECKS 6.2-26 
RCV_PACING RSP 6.2-29 
SEND _TO PC 6.2-22 
IPR 
See ISOLATED PACING RESPONSE (IPR) 
ISOLATED PACING MESSAGE (IPM) 
See also session-level pacing 
reset acknowledgment IPM 6.2-8 
solicited IPM 6.2-8 
unsolicited IPM 6.2-8 
ISOLATED PACING RESPONSE (IPR) 
See session-level pacing 


last resource 
See sync point, flows, last resource opti- 
mization 
layer of SNA 2-4, 2-27 
length prefix (LL) 2-3, 2-13, 2-15, 2-30; 
5.1-6 
accumulation and checking 2-30, 2-31 
LFSID_IN_USE 4-12 
LFSID_IN_USE_RSP 4-13 
LFSID_IN_USE_RSP structure A-25 
referenced by 
PROCESS _LFSID_IN USE 4-82 
LFSID_IN_USE structure A-26 
referenced by 
PROCESS_LFSID_IN_USE 4-82 
PROCESS RECORD_FROM_ASM 4-51 
LFSID structure A-28 
limited buffer pool 
See buffer, pools 
limited buffers 
See buffer, types 
link buffers 
See buffer, types 
LL 
See length prefix (LL) 
LLID 
See general data stream header 
local LU characteristics 2-40 
local LU name 
See LU name, local 
local resources 
See resource, local 
See sync point, local resources 
LOCAL_SESSION_LIMIT_PROC procedure 5.4-42 
referenced by 
INITIALIZE SESSION_LIMIT_PROC 5.4-34 
RESET _SESSION_LIMIT_PROC 5.4-35 
LOCAL structure 4-89, 6.0-7 
referenced by : 
BIND_RQ_STATE_ERROR 4-52 
BIND_RSP_STATE_ERROR 4-54 
BIND SESSION _LIMIT EXCEEDED 4-57 
BUILD_AND_SEND_BIND_RSP_NEG 4-60 
BUILD AND SEND INITHS 4-61 
BUILD _AND_SEND SESSEND_SIG 4-64 
BUILD AND SEND UNBIND RQ 4-65 
BUILD_BIND_RSP_POS 4-67 
DFC_INITIALIZE 6.1-19 
DFC_RCV 6.1-24 
DFC_RCV_FSMS 6.1-25 
DFC_SEND_FROM_PS 6.1-20 
DFC_SEND_FROM_RM 6.1-21 
DFC_SEND_FSMS 6.1-27 
DFC_SEND TO PS 6.1-30 
FORMAT_ERROR 6.1-31 
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FORMAT_ERROR_EXP_RSP 6.1-32 
FORMAT_ERROR_NORM_RSP 6.1-32 
FORMAT_ERROR_RQ_DFC 6.1-33 
FORMAT_ERROR_RQ FMD 6.1-34 
FSM_BSM_FMP19 6.1-50 
FSM_CHAIN_RCV_FMP19 6.1-51 
FSM_CHAIN_SEND_FMP19 6.1-53 
. FSM_QRI_CHAIN_RCV_FMP19 6.1-55 
FSM_STATUS 4-87 . 
GENERATE_RM_PS_INPUTS 6.1-36 
HS 6.0-3 
INITIALIZE _LULU_CB_BIND 4-71 
INVALID_SENSE_CODE 6.1-38_ 
LU_MODE_SESSION_LIMIT_EXCEEDED 4-72 
OK TO_REPLY 6.1-39 
PREPARE_TO_SEND_BIND 4-73 
PROCESS _ABEND_NOTIFICATION 4-74 
PROCESS ABORT_HS 4-74 
PROCESS _BIND_RQ 4-76 
PROCESS _BIND_RSP 4-78 
PROCESS CINIT_SIGNAL 4-79 
PROCESS_LU_LU_SESSION 6.0-5 
PROCESS RU_DATA 6.1-40 
RCV_STATE_ERROR 6.1-41 
REPLY_TO_BID 6.1-42 
RESERVE _CONSTANT_BUFFERS 4-84 
RESERVE_VARIABLE_BUFFERS 4-84 
SEGMENT_REASSEMBLY 6.2-28 
SEND_BID_POS_ RSP 6.1-42 
SEND_FMD MU 6.1-43 
SEND_RSP_IF_ REQUIRED 6.1-44 
SEND_RSP_MU 6.1-45 
SEND_RSP_TO_RM_OR PS 6.1-46 
SIGNAL_STATUS 6.1-47 
SM 4-48 
STRAY_RSP 6.1-48 
TC.BIU_RCV_CHECKS 6.2-25 
TC.CRV_FORMAT_CHECK 6.2-18 
TC.DECIPHER_RU 6.2-32 
TC. EXCHANGE_CRV 6.2-15 
TC.INITIALIZE 6.2-13 
TC.RCV 6.2-23 
TC.SEGMENT_RCV_CHECKS 6.2-24¢ 
TRANSLATE 6.1-49 
TRY_TO_RCV_SIGNAL 6.1-23 
LOCAL_VERB_PARAMETER_CHECK procedure 5.4-43 
referenced by 
LOCAL_SESSION_LIMIT_PROC 5.4-42 
local, role of LU and TP 2-5 
lock manager 
See sync point, heuristic decision, and 
lock manager 
log manager 5.3-3, 5.3-19, 5.3-20, 5.3-25, 
5.3-32, 5.3-33, 5.3-34 
log mismatch 5.3-33, 5.3-34 
See also sync point, log 
log name 
See sync point, log 
logging 2-4 
See also sync point, logging 
logical record 2-13, 2-15, 2-30, 5.1-6 
logical unit (LU) 
See LU (logical unit) 
logical unit of work 
See sync point 
logical unit of work (LUW) 5.3-1, 5.3-3, 
5.3-16, 5.3-19, 5.3-24, 5.3-25, 5.3-30, 
5.3-32 
delimiting 5.3-1, 5.3-20, 5.3-32 
distributed 5.3-4 
local 5.3-4 
state of 5.3-4, 5.3-18, 5.3-20, 5.3-22, 
5.3-24, 5.3-25, 5.3-30, 5.3-32 


O 
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LOGICAL UNIT STATUS (LUSTAT) 6.1-4, 6.1-5, 
6.1-11, 6.1-14, 6.1-15, 6.1-16 
loser, contention 
See bracket, bidder 
LU (logical unit) 2-1 
association with end users 1-3 
component interaction 2-48 
control block (LUCB) 5.1-2 
creation 2-43 
definition 1-3 
parallel-session 5.4-3 
peripheral 1-5 
single-session 5.4-3 
structure 2-27 
subarea 1-5 
LU data structures 
LU control block (LUCB) 5.2-4 
transaction program control block 
(TPCB) 5.2-4 
LU definition 5.4-3 
LU-LU password 4-18 
See also session-level security, LU-LU 
password 
LU-LU session 
See session 
LU-LU verification 4-18 
See also session-level security, LU-LU 
verification 
LU mode 2-4 
LU-mode entry 5.4-5, 5.4-12 
locking for CNOS 
See change number of sessions (CNOS), 
locking (LU,mode) entry 
processing by PS.COPR (CNOS) 5.4-8, 
5.4-28 
LU_MODE_SESSION_LIMIT_EXCEEDED proce- 
dure 4-72 
referenced by 
BIND_RSP_STATE_ERROR 4-54 
BIND_SESSION_LIMIT_EXCEEDED 4-57 
PROCESS _ACTIVATE_SESSION 4-75 
PROCESS CINIT_SIGNAL 4-79 
LU name 2-6), 2-32 
fully qualified 
See LU name, network-qualified 
local 2-6, 2-40 
network-qualified 2-6, 2-40 
uninterpreted 2-40 
LU_NAME structure 3-91 
referenced by 
ACTIVATE_NEEDED_SESSIONS. 3-24 
BIS _RACE_LOSER 3-38 
CREATE_SCB 3-44 
DEACTIVATE_FREE_SESSIONS 3-46 
DEACTIVATE_PENDING SESSIONS 3-47 
SEND_ACTIVATE_SESSION 3-65 
SESSION_ACTIVATION_POLARITY 3-71 
SESSION_DEACTIVATION_POLARITY 3-74 
SHOULD_SEND_BIS 3-76 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
LU services manager 
See resources manager (RM) 
See session manager (SM) 
LU services record 


See Change Number of Sessions GDS variable 


LU session manager (SM) 

See session manager (SM) 
LUCB_LIST_PTR structure 5.0-24 
LUCB structure 2-40, A-1 

referenced by 

BIND_RQ_STATE_ERROR 4-52 
BUILD_AND_SEND_BIND_RQ 4-59 
BUILD AND SEND INIT SIG 4-61 


LUL 


LUS 
LUN 


CHECK_CNOS_REPLY 5.4-56 
CREATE_TCB_AND_PS 3-45 
DEFINE PROC 5.4-39 
DELETE_PROC 5.4-41 
DISPLAY_PROC 5.4-40 
GET_TP_PROPERTIES_PROC 5.0-18 
LOCAL_VERB_PARAMETER_CHECK 5.4-43 
PROCESS SESSION_LIMIT_PROC 5.4-58 
PS 5.0-8 
PS_CREATION_PROC 3-55 
PS _TERMINATION_PROC 3-57 
SECURITY_PROC 3-65 
SESSION_LIMIT_DATA_LOCK_MANAGER 5.4-67 
SM 4-48 
SOURCE_CONVERSATION_CONTROL 5.4-49 
START_TP_PROC 3-77 
SVCMG_VERB_PARAMETER_CHECK 5.4-44 
VERB_PARAMETER_CHECK 5.4-48 

U_CB structure 4-90 

referenced by 
BIND_RSP_STATE_ERROR 4-54 
BUILD_AND_SEND_ACT_SESS_RSP_NEG 4-58 
BUILD_AND_SEND_ACT SESS RSP_POS 4-58 
BUILD_AND_SEND_BIND_RQ 4-59 
BUILD_AND SEND _FREE_LFSID 4-60 
BUILD_AND_SEND_INIT_HS 4-61 
BUILD _AND_SEND_INIT SIG 4-61 
BUILD _AND_ SEND PC_HS DISCONNECT 4-62 
BUILD _AND_SEND_SESS_ ACTIVATED 4-63 
BUILD AND SEND SESSEND SIG 4-64 
BUILD_AND_SEND_SESSST_SIG 4-65 
BUILD AND SEND _UNBIND RQ 4-65 
BUILD _AND_SEND_UNBIND_RSP 4-66 
BUILD _BIND_RSP_POS 4-67 
CLEANUP_LU_LU_SESSION 4-67 
FSM_STATUS 4-87 
GET_FQPCID 4-70 
INITIALIZE_LULU_CB_ACT_SESS 4-70 
INITIALIZE _LULU_CB_ BIND 4-71 
PREPARE_TO SEND BIND 4-73 
PROCESS _ABEND_NOTIFICATION 4-74 
PROCESS ABORT_HS 4-74 
PROCESS _ACTIVATE_SESSION 4-75 
PROCESS BIND RQ 4-76 
PROCESS _BIND_RSP 4-78 
PROCESS CINIT_SIGNAL 4-79 
PROCESS DEACTIVATE_SESSION 4-80 
PROCESS INIT_HS RSP 4-81 
PROCESS _INIT_SIGNAL_NEG_RSP 4-81 
PROCESS SESSION_ROUTE_INOP 4-83 
PROCESS UNBIND_RQ 4-83 
RESERVE_CONSTANT_BUFFERS 4-84 
RESERVE_VARIABLE_BUFFERS 4-84 
SM 4-48 

TAT (LOGICAL UNIT STATUS) 6.1-16 


See logical unit of work (LUW) 


i 


map 2-36 
map name 2-36 


globally Known 2-37 
receiver locally Known 2-37 
sender locally Known 2-37 


mapped conversation 2-3, 2-12, 5.2-3, 5.2-5 


See also conversation 

data stream format 5.2-5 
errors 5.2-14, 5.2-16, 5.2-17 
function summary 5.2-1 
initiation 5.2-7 


Index X-13 


x-14 


SNA LU 6.2 Reference: 


protocol boundary 5.2-1 
termination 5.2-7 
mapped-conversation message 2-14 
mapped-conversation record 2-13, 2-15, 2-30 
mapper 2-37 
mapping 2-7, 2-12, 2-15, 2-30, 2-36, 5.2-1, 
5.2-8 
errors 5.2-15 
map names 5.2-8, 5.2-9, 5.2-12 
mapper 5.2-8, 5.2-11, 5.2-12, 5.2-14 
parameters 5.2-10 
save area 5.2-4, 5.2-8, 5.2-9 
receive mapping 5.2-11 
receive-buffer list 5.2-4 
send mapping 5.2-9, 5.2-10 
maximum send size 5.2-5, 5.2-4 


MC_ALLOCATE_PROC procedure 5.2-21 


referenced by 
PS MC 5.2-20 
MC_CONFIRM_PROC procedure 5.2-21 
referenced by 
PS MC 5.2-20 
MC_CONFIRMED_PROC procedure 5.2-22 
referenced by 
PS MC 5.2-20 
MC_DEALLOCATE_PROC procedure 5.2-23 
referenced by 
PS MC 5.2-20 
MC_FLUSH_PROC procedure 5.2~-23 
referenced by 
PS MC 5.2-20 
MC_GET_ATTRIBUTES PROC procedure 5.2-24 
referenced by 
PS MC 5.2-20 
MC_POST_ON_RECEIPT_PROC procedure 5.2-25 
referenced by 
PS MC 5.2-20 
MC_PREPARE_TO_RECEIVE_PROC procedure 5.2-26 
referenced by 
PS MC 5.2-20 
MC_RECEIVE_AND_WAIT_PROC procedure 5.2-27 
referenced by " 
PS MC 5.2-20 
MC_REQUEST_TO_SEND_PROC procedure 5.2-37 
referenced by 
PS MC 5.2-20 
MC_SEND_DATA_PROC procedure 5.2-38 
referenced by 
PS MC 5.2-20 
MC_SEND_ERROR_PROC procedure 5.2-40 
referenced by 
PS MC 5.2-20 
MC_TEST_PROC procedure 5.2-28 
referenced by 
PS MC 5.2-20 
TEST_FOR_RESOURCE_POSTED 5.0-21 
message unit (MU) 2-13, 2-30, 4-11 
basic conversation 2-13 
conversation sequences 2-14 
data record | 
See data record 
header 2-13 
length limitations 2-13, 2-14 
mapped conversation 2-13 
session 2-14 
session sequences 2-15 
message-unit transformation 
basic conversation 2-15, 2-30 
mapped conversation 2-15, 2-30 
See also mapping 
message units 
CNOS 


See Change Number of Sessions GDS vari- 


able 


Peer Protocols 


mode 
control block 3-4, 5.1-3 
mode name 2-6, 2-32, 2-40, 4-18 
deriving BIND image from 4-18 
in INIT_SIGNAL 4-9 
MODE_NAME structure 3-91 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-24 
BIS RACE LOSER 3-38 
CREATE_SCB 3-44 
DEACTIVATE_FREE_SESSIONS 3-46 
DEACTIVATE_PENDING_ SESSIONS 3-47 
SEND_ACTIVATE_SESSION 3-65 
SESSION_ACTIVATION_POLARITY 3-71 
SESSION_DEACTIVATION_POLARITY 3-74 
SHOULD SEND BIS 3-76 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
MODE structure 2-40, A-3 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-24 
ACTIVATE_SESSION_RSP_PROC 3-25 
ALLOCATE_PROC 5.1-11 
BID_PROC 3-33 
BIND_RQ STATE_ERROR 4-52 
BIND _RSP_STATE_ERROR 4-54 
. BIND_SESSION_LIMIT_EXCEEDED 4-57 
BIS RACE_LOSER 3-38 
CHANGE_ACTION 5.4-44 
CHANGE_SESSIONS_ PROC 3-39 
CHECK_CNOS_COMMAND 5.4-63 
CHECK_CNOS REPLY 5.4-56 
CHECK_FOR_BIS_ REPLY 3-40 
CLOSE_ONE_REPLY 5.4-65 
DEACTIVATE_PENDING_SESSIONS 3-47 
DEFINE_PROC 5.4-39 
DELETE_PROC 5.4-41 
DEQUEUE_WAITING_REQUEST 3-48 
DISPLAY_PROC 5.4-40 
LOCAL_VERB_PARAMETER_CHECK 5.4-43 
LU_MODE_SESSION_LIMIT_EXCEEDED 4-72 
NEGOTIATE_REPLY 5.4-64 
PROCESS ACTIVATE_SESSION 4-75 
PROCESS_CINIT_SIGNAL 4-79 
PROCESS SESSION_LIMIT_PROC 5.4-58 
PS ABEND PROC 3-54 
SEND_ACTIVATE_SESSION 3-65 
SEND_BIS_REPLY 3-67 
SEND_BIS_RQ 3-67 
SEND_DEACTIVATE_SESSION 3-68 
SESSION_ACTIVATED_PROC 3-70 
SESSION_ACTIVATION_POLARITY 3-71 
SESSION_DEACTIVATED_PROC 3-72 
SESSION_DEACTIVATION_ POLARITY 3-74 
SESSION_LIMIT_DATA_LOCK_MANAGER 5.4-67 
SHOULD_SEND_BIS 3-76 
SM 4-48 
SOURCE _CONVERSATION_CONTROL 5.4-49 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
SVCMG_VERB_PARAMETER_CHECK 5.4-44 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
VERB_PARAMETER_CHECK 5.4-48 
MODE, CONTROL 
See CONTROL MODE 
mode » LU 2-3) 2-4> 2-65 2-40 
See also transport characteristics 
MU 
See message unit (MU) 
MU_PACING_CHECKS procedure 
referenced by 
TC.SEGMENT_RCV_CHECKS 
MU structure A-29 
referenced by 
ATTACH_ERROR_PROC 5.0-15 


6.2-26 


6.2-24 


Co 


C 
ew 


ATTACH_PROC 3-30 

BIND_RQ STATE_ERROR 4-52 
BIND_RSP_STATE_ERROR 4-54 
BUFFERS_RESERVED_PROCESSING 6.2-31 
BUILD_AND_SEND_BIND_RQ 4-59 
BUILD _AND_SEND_BIND_RSP_NEG 4-60 
BUILD_AND_SEND_UNBIND_RQ 4-65 
BUILD _AND_SEND_UNBIND_RSP 4-66 
BUILD _BIND_RSP_POS 4-67 
BUILD_HS_TO_PS HEADER 6.1-28 
COMPLETE_CONFIRM_PROC 5.1-28 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-29 
CONFIRM_PROC 5.1-12 
CORRELATE_BIND_RSP 4-68 
CORRELATE_UNBIND_RQ 4-69 
CREATE_AND_INIT _LIMITED_MU 5.1-30 
CT_UPDATE 6.1-29 
DEALLOCATE_CONFIRM_PROC 5.1-32 
DEALLOCATE_FLUSH_PROC 5.1-33 
DFC_INITIALIZE 6.1-19 

DFC_RCV 6.1-24 

DFC_RCV_FSMS 6.1-25 
DFC_SEND_FROM_PS 6.1-20 
DFC_SEND_FROM_RM 6.1-21 
DFC_SEND_FSMS 6.1-27 
DFC_SEND_TO_PS 6.1-30 
END_CONVERSATION PROC 5.1-34 
FLUSH_PROC 5.1-16 

FORMAT_ERROR 6.1-31 

FORMAT _ERROR_EXP_RSP 6.1-32 
FORMAT_ERROR_NORM_RSP 6.1-32 
FORMAT_ERROR_RQ_DFC 6.1-33 
FORMAT_ERROR_RQ_FMD 6.1-34 
FSM_BSM_FMP19 6.1-50 | 
FSM_CHAIN_RCV_FMP19 6.1-51 
FSM_CHAIN_SEND_FMP19 6.1-53 
FSM_CONVERSATION 5.1-65 
FSM_ERROR_OR_FAILURE 5.1-67 
FSM_QRI_CHAIN_RCV_FMP19 6.1-55 
FSM_RCV_PURGE_FMP19 6.1-56 
FSM_STATUS 4-87 

GENERATE. RM_PS_INPUTS 6.1-36 
GET_END_CHAIN_FROM_HS 5.1-36 
INITIALIZE_LULU_CB BIND 4-71 
INITIALIZE TH_RH 6.1-38 

INVALID SENSE CODE 6.1-38 
MU_PACING CHECKS 6.2-26 

OBTAIN SESSION PROC 5.1-37 
OK_TO_REPLY 6.1-39 

PERFORM _RECEIVE_ PROCESSING 5.1-40 


PREPARE_TO_RECEIVE CONFIRM_PROC 5.1-41 


PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-42 
PROCESS BIND_RQ 4-76 

PROCESS BIND RSP 4-78 
PROCESS _FMH5 5.0-10 

PROCESS FMH7_PROC 5.1-46 
PROCESS _HS_TO_RM_RECORD 3-20 
PROCESS MU 4-82 
PROCESS_RECORD_FROM_ASM 4-51 
PROCESS RU_DATA 6.1-40 
PROCESS_UNBIND_RQ 4-83 

PS 5.0-8 

PS_ABEND_PROC 3-54 

PS _ATTACH_CHECK 5.0-12 

PS _CREATION_PROC 3-55 

PS TERMINATION PROC 3-57 
PURGE_QUEUED_REQUESTS 3-59 
QUEUE_ATTACH_PROC 3-60 
RCB_ALLOCATED_PROC 5.1-48 
RCV_PACING_RSP 6.2-29 
RCV_STATE_ERROR 6.1-41 
RECEIVE PACING 6.2-27 
RECEIVE_RM_OR_HS_TO_PS_RECORDS 5.1-51 
REPLY TO BID 6.1-42 


RESERVE_VARIABLE_BUFFERS 4-84 
SECURITY_PROC 3-65 
SEGMENT_REASSEMBLY 6.2-28 
SEND_ATTACH_TO PS 3-66 
SEND_BID_POS_RSP 6.1-42 
SEND_CONFIRMED_PROC 5.1-53 


SEND_DATA_BUFFER_MANAGEMENT 5.1-54 


SEND_DATA_PROC 5.1-24 
SEND_ERROR_DONE_PROC 5.1-55 


SEND_ERROR_IN_RECEIVE_STATE 5.1-56 


SEND_ERROR_IN_ SEND STATE 5.1-57 
SEND_ERROR_TO_HS_ PROC 5.1-58 
SEND_FMD_MU 6.1-43 

SEND_MU 6.2-20 

SEND_PACING 6.2-21 


SEND_REQUEST_TO_SEND_PROC 5.1-58 


SEND_RSP_IF_REQUIRED 6.1-44 
SEND_RSP_MU 6.1-45 
SEND_RSP_TO_RM_OR_PS 6.1-46 
SEND_TO_PC 6.2-22 
SESSION_DEACTIVATED_PROC 3-72 
STRAY_RSP 6.1-48 
TC.BIU_RCV_CHECKS 6.2-25 
TC.BUILD_CRV 6.2-17 

TC .CRV_FORMAT_CHECK 6.2-18 
TC.DECIPHER_RU 6.2-32 

TC .EXCHANGE_CRV 6.2-15 

TC.RCV 6.2-23 
TC.SEGMENT_RCV_CHECKS 6.2-24 
TEST_FOR_POST_SATISFIED 5.1-60 
TRANSLATE 6.1-49 


WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-63 


multiple-session LU 
See session, parallel 


[Ls] 


name 2-4 
fully qualified LU 
See LU name, network-qualified 
local alias 2-5 
LU 
See LU name 
mode 
See mode name 
network-qualified LU 
See LU name, network-qualified 
name translation 2-5 
naming conventions 
using periods 1-5 
using underscores 1-5 
NAU 
See network addressable unit (NAU) 
NAU (network addressable unit) 
definition 1-3 
negotiable BIND 4-20, 4-24 
NEGOTIATE_REPLY procedure 5.4-64¢ 
referenced by 


PROCESS_SESSION_LIMIT_PROC 5.4-58 


nested nodes 1-4 
network 

path control 1-3, 1-5 

SNA 1-3 
network addressable unit (NAU) 2-17 
network ID 2-6 
network LU name 2-6 
network name of LU 

See network qualified name 
network-qualified LU name 

See LU name, network-quali fied 
network qualified name 4-18 


Index 


X-15 


X-16 


no-op finite-state machines N-1 
node 
definition 1-3 
SNA 1-3, 1-4 
SNA product 1-3, 1-4 
_ synonymous with "SNA node" 1-3 
type 


user-application 1-3, 1-4 
node operator facility (NOF) 2-29, 2-36; 
2-43, 3-3 
nodes 
nesting of 1-3; 1-4 
NOF 
See node operator facility (NOF) 
non-SNA functions 
See also implementation-determined func- 
tions 
API 2-4 
error recovery 2-10 
mapping 2-36 
names 2-5 
resources 2-10, 2-29, 2-38 
local 2-4 
normal flow 6.2-1 
TC 6.2-6 
normal-flow send/receive mode 
See send/receive mode 
notational conventions, general 1-5 


fo | 


OBTAIN_SESSION_PROC procedure 5.1-37 
referenced by 
RCB_ALLOCATED_PROC 5.1-48 
OK_TO_REPLY procedure 6.1-39 
referenced by 
FSM_CHAIN_RCV_FMP19 6.1-51 
FSM_CHAIN _SEND_FMP19 6.1-53 
GENERATE_RM_PS_INPUTS 6.1-36 
REPLY_TO BID 6.1-42 
one-way conversation 2-6 
operation 
receiver 6.2-9 
sender 6.2-9 
operator 
See control operator 
operator messages, sync point 
See sync point, operator messages 
optimized flows 
See sync point, flows 
optional function sets 2-12, 2-36, 2-40 
CNOS 5.4-22 
receive options 2-12 
send options 2-12 
origin transaction program 2-7 


SNA LU 6.2 Reference: Peer Protocols 


A 


pacing 
See also initialization 
See also session-level pacing 
initialization 6.2-3 
pacing queue 6.2-8 
queued response indicator (QRI) 6.2-8 
session-level 6.2-1, 6.2-6 
IPM 6.2-8 
IPR 6.2-8 
pacing algorithms 
adaptive 6.2-8 
fixed 6.2-8 
Pacing Request indicator (PI) 6.2-7 
Pacing Response indicator (PI) 6.2-7, 6.2-8 
Padded Data indicator (PDI) 6.2-6 
parallel session 
See session, parallel 
parallel session LU 2-7, 2-36 — 
See also session, parallel - | 
partner LU 2-4, 2-40 \ 
See also remote, role of LU and TP 
control block 5.1-3 
PARTNER_LU structure 2-40, A-2 
referenced by 
BIND_RQ_STATE_ERROR 4-52 
BIND_RSP_STATE_ERROR 4-54 
BIND_SESSION_LIMIT_EXCEEDED 4-57 
CHANGE_ACTION 5.4-44 
CHECK_CNOS_REPLY 5.4-56 
DEFINE_PROC 5.4-39 
DELETE_PROC 5.4-41 


DISPLAY_PROC 5.4-40 es, 
GET_ATTRIBUTES_PROC 5.1-17 : 
GET_SESSION_PROC 3-52 \- 


INITIALIZE_LULU_CB_ACT_SESS 4-70 
INITIALIZE_LULU_CB_ BIND 4-71 
NEGOTIATE_REPLY 5.4~-64 
PROCESS _ACTIVATE_SESSION 4-75 
PROCESS BIND_RQ 4-76 
PROCESS BIND_RSP 4-78 
PROCESS CINIT_SIGNAL 4-79 
PROCESS _SESSION_LIMIT_PROC 5.4-58 
SESSION_ACTIVATION_POLARITY 3-71 
SESSION_DEACTIVATED_PROC 3-72 
SESSION_LIMIT_DATA_ LOCK__ MANAGER 5.4-67 oe 
SHOULD_SEND_BIS 3-76 ‘ 
SM 4-48 Lae 
SOURCE_CONVERSATION_CONTROL 5.4-49 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
password 
See conversation-level security 
See session-level security 
path control network 1-3, 1-5, 2-1, 2-27 
protocol boundary with LU 2-47 
PC 
See path control network | 
PC_CHARACTERISTICS structure A-32 
PC_HS DISCONNECT 4-11 
PC_HS DISCONNECT structure A-24 
referenced by 
BUILD_AND_SEND_PC_HS DISCONNECT 4-62 
PDI 
See Padded Data indicator (PDI) 
PERFORM_RECEIVE_EC_PROCESSING proce- 
dure 5.1-38 


referenced by ’ 
PERFORM_RECEIVE_ PROCESSING 5.1-40 


PERFORM_RECEIVE_PROCESSING procedure 5.1-40 ae 
referenced by 
RECEIVE_AND_TEST_POSTING 5.1-50 


RECEIVE_IMMEDIATE_PROC 5.1-21 
performance-related options 2-12 
periods, separating name qualifiers denoting 

decomposition 1-5 
peripheral LU 1-5 
peripheral node 1-4 
See also node 
peripheral node to peripheral node communi- 
cation 2-1 
peripheral node to subarea node communi- 
cation 2-1 
peripheral PU 1-5 
permanent buffer pool 
See buffer, pools 
permanent buffers 
See buffer, types 
phases, sync point 
See sync point, commands 
physical unit (PU) 
See PU (physical unit) 
PI 
See Pacing Request or Pacing Response 
indicator (PI) 
PIP | 
See program initialization parameters 
(PIP ) 
PLU 
See primary LU (PLU) 
PLU name 
in BIND 4-22 
POST_ON_RECEIPT_PROC procedure 5.1-17 
referenced by 

MC_POST_ON_RECEIPT_PROC 5.2-25 

MC_TEST_PROC 5.2-28 

PS CONV 5.1-10 
Prepare 

See sync point, commands, Prepare 
PREPARE_TO_RECEIVE_CONFIRM_PROC proce- 
dure 5.1-41 

referenced by 

PREPARE_TO_RECEIVE PROC 5.1-18 
PREPARE_TO_RECEIVE_FLUSH_PROC proce- 

dure 5.1-42 
referenced by 

PREPARE_TO_RECEIVE PROC 5.1-18 
PREPARE_TO_RECEIVE_PROC procedure 5.1-18 

referenced by 

MC_PREPARE_TO_RECEIVE_PROC 5.2-26 

PS CONV 5.1-10 

SEND_SVC_ERROR_PURGING 5.2-45 
PREPARE_TO_SEND_BIND procedure 4-73 

referenced by 

PROCESS CINIT_SIGNAL 4-79 
presentation services (PS) 5.0-1, 5.2-1 

creation 3-18 

data structures 5.2-4 

function summary 2-34 

process 2-32, 5.0-4, 5.0-5, 5.0-6 

protocol boundaries 2-47, 5.0-2 

structure 2-29, 5.0-2, 5.1-1 

termination 3-18 
presentation services (PS) headers 2-38, 
5.1-6, 5.3-6, 5.3-7, 5.3-8, 5.3-35 
presentation services (PS) initialize 2-29, 
5.0-4 

See also presentation services (PS) 

protocol boundaries 5.0-3, 5.0-4 
presentation services (PS) verb router 2-29, 
5.0-7 

See also presentation services (PS) 
presentation services for conversations 
(PS.CONV) 2-29 

See also presentation services (PS) 

function summary 5.1-1 


protocol boundaries 2-46, 5.1-1 
structure 5.1-1 
presentation services for mapped conversa- 
tions (PS.MC) 2-29, 2-36 
See also mapped conversation 
See also mapping 
See also presentation services (PS) 
protocol boundaries 2-46 
presentation services for sync point services 
(PS.SPS) 2-29, 2-38 
See also presentation services (PS) 
See also sync point 
protocol boundaries 2-38 
presentation services for the control opera- 
tor (PS.COPR) 2-29, 5.4-1, 5.4-22 
See also change number of sessions (CNOS) 
See also presentation services (PS) 
local-verb services 5.4-25 
protocol boundaries 2-46 
session-limit-data lock 5.4-12, 5.4-32 
session-limit-data-lock manager 5.4-12; 
5.4-15, 5.4-31 
shared data 5.4-12 
See also LU-mode entry 
source-LU session-limit services 5.4-12, 
5.4-15, 5.4-26 
See also change number of sessions 
(CNOS), component relationship, 
source-LU services 
structure 5.4-1, 5.4-24 
target-LU session-limit services 5.4-12; 
5.4-15, 5.4-29 
See also change number of sessions 
(CNOS), component relationship, 
target-LU services 
verb router 5.4-25 
presentation services verb router 5.2-3 
presentation space 2-7 
PREVIOUS TIME structure 3-92 
referenced by 
COMPLETE_LUW_ID 3-41 
RM 3-19 
primary LU (PLU) 2-8, 2-33 
See also session, activation polarity 
primary LU name 
in BIND 4-22 
process 2-40 
PROCESS_ABEND_NOTIFICATION procedure 4-74 
referenced by 
PROCESS _RECORD_FROM_HS 4-50 
PROCESS RECORD FROM RM 4-49 
PROCESS ABORT_HS procedure 4-74 
referenced by 
PROCESS RECORD_FROM_HS 4-50 
PROCESS _ACTIVATE_SESSION procedure 4-75 
referenced by 
PROCESS RECORD_FROM_RM 4-49 
PROCESS BIND_RQ procedure 4-76 
referenced by 
PROCESS MU 4-82 
PROCESS BIND_RSP procedure 4-78 
referenced by 
PROCESS MU 4-82 
PROCESS CINIT_SIGNAL procedure 4-79 
referenced by 
PROCESS RECORD FROM_SS 4-50 
process connection 2-32, 2-34 
PROCESS DATA_COMPLETE procedure 5.2-33 
referenced by 
RECEIVE INFO PROC 5.2-30 
PROCESS DATA_INCOMPLETE procedure 5.2-36 
referenced by 
RECEIVE INFO_PROC 5.2-30 
PROCESS DATA_PROC procedure 5.1-43 


Index X-17 


referenced by 
PERFORM_RECEIVE_ PROCESSING 5.1-40 
PROCESS DEACTIVATE_SESSION procedure 4-80 
referenced by 
PROCESS RECORD_FROM_RM 4-49 
PROCESS _ERROR_DATA procedure 5.2-43 
referenced by 
RCVD_SVC_ERROR_PURGING 5.2-42 
PROCESS _ERROR_OR_FAILURE_RC procedure 5.2-31 
referenced by 
MC_TEST_PROC 5.2-28 
RECEIVE_INFO_PROC 5.2~-30 
PROCESS_FMHS procedure 5.0-10 
referenced by 
PS 5.0-8 . 
PROCESS _FMH7_LOG_DATA_PROC procedure 5.1-44 
referenced by 
PROCESS FMH7_PROC 5.1-46 
PROCESS_FMH7_PROC procedure 5.1-46 
referenced by 
DEQUEUE_FMH7_PROC 5.1-34 
PERFORM_RECEIVE_ PROCESSING 5.1-40 
PROCESS_HS_TO_RM_RECORD procedure 3-20 
referenced by 
RM 3-19 
PROCESS _INIT_HS_RSP procedure 4-81 
referenced by 
PROCESS RECORD FROM_HS 4-50 
PROCESS _INIT_SIGNAL_NEG_RSP procedure 4-81 
referenced by 
PROCESS _RECORD_FROM_SS 4-50 
PROCESS _INITIATOR_TO_RM_RECORD proce- 
dure 3-20 
referenced by 
RM 3-19 
PROCESS _LFSID_IN_USE procedure 4-82 
referenced by 
PROCESS RECORD_FROM_ASM 4-51 
PROCESS LU_LU_SESSION procedure 6.0-5 
referenced by 
HS 6.0-3 
PROCESS MAPPER_RETURN CODE procedure 5.2-35 
referenced by 
PROCESS DATA_COMPLETE 5.2-33 
PROCESS_MU procedure 4-82 
referenced by 
PROCESS RECORD_FROM_ASM 4-51 
PROCESS PS _TO_RM_RECORD procedure 3-22 
referenced by 
RM 3-19 
PROCESS _RECORD_FROM_ASM procedure 4-51 
referenced by 
SM 4-48 
PROCESS RECORD_FROM_HS procedure 4-50 
referenced by 
SM 4-48 
PROCESS_RECORD_FROM_RM procedure 4-49 
referenced by 
SM. 4-48 
PROCESS_RECORD_FROM_SS procedure 4-50 
referenced by 
SM 4-48 
PROCESS RU_DATA procedure 6.1-40 
referenced by 
GENERATE_RM_PS_INPUTS 6.1-36 
PROCESS SESSION_LIMIT_PROC procedure 5.4-58 
referenced by 
PS COPR 5.4-33 
PROCESS SESSION_LIMIT verb 5.4-6 
processing by PS.COPR 5.4-23, 5.4-29 
PROCESS SESSION _ROUTE_INOP procedure 4-83 
referenced by 
PROCESS _RECORD_FROM_ASM 4-51 
PROCESS SM_TO_RM_RECORD procedure 3-23 
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referenced by 


RM 3-19 \ 
PROCESS START_TP procedure 5.0-11 (— 
referenced by Seen 
PS 5.0-8 
PROCESS UNBIND_RQ procedure 4-83 
referenced by 
PROCESS MU 4-82 
profile, security 
See conversation-level security 
profiles 2-9 
FM (function management) profile 19 2-9 
TS (transmission services) profile 7 2-9 
program initialization parameters 
(PIP) 2-12, 5.0-4, 5.0-5 
program-to-program communication -2-1 
protection 
See sync point 
protection manager 
See sync point, protection manager 
protocol boundary 2-4, 2-46 
See also application program interface 


(APT) C- 
See also session manager (SM), protocol . 
boundary | = 
See also under individual component 
between layers 2-4 
between peer components 2-4 
general definition 1-1 
in BIND 
internal 2-27, 2-46 
partitioned 2-4 
PROTOCOL_ERROR_PROC procedure 5.2-47 
referenced by 
GET_SEND_INDICATOR 5.2-44¢ 
MC_TEST_PROC 5.2-28 | 
PROCESS DATA_COMPLETE 5.2-33 C™ 
PROCESS DATA_INCOMPLETE 5.2-36 Neco? 
PROCESS _ERROR_DATA 5.2-43 
PROCESS ERROR_OR_FAILURE_RC 5.2-31 
PROCESS MAPPER_RETURN_CODE 5.2-35 
RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
RECEIVE _INFO_PROC 5.2-30 
SEND_SVC_ERROR_PURGING 5.2-45 
protocol machine, definition of 1-1 
PS 
See presentation services (PS) 
PS ABEND _PROC procedure 3-54 fo 
referenced by ( | 
PROCESS PS _TO_RM_RECORD 3-22 Ne 
PS _ATTACH_CHECK procedure 5.0-12 
referenced by 
PROCESS FMH5 5.0-10 
PS .CONV 
See presentation services for conversa- 
tions (PS.CONV) 
PS _ CONV procedure 5.1-10 
referenced by 
PS_VERB_ROUTER 5.0-16 
PS.COPR 
See presentation services for the control 
operator (PS.COPR) 
PS _COPR procedure 5.4-33 
referenced by 
PS_VERB_ROUTER 5.0-16 
PS _CREATE_PARMS structure A-27 
referenced by 
CREATE_TCB_AND PS 3-45 


PS 5.0-8 sa 
PS CREATION PROC 3-55 


PS_CREATION_PROC procedure 3-55 
referenced by 
ATTACH _PROC 43-30 


f™ 


& 


PS header 
See presentation services (PS) headers 
PS .MC 
See presentation services for mapped con- 
versations (PS.MC) 
PS_ MC procedure 5.2-20 
referenced by 
PS_VERB_ROUTER 5.0-16 
PS PIP_CHECKS procedure 5.0-13 
referenced by 
PROCESS FMHS 5.0-10 
PS process 5.0-8 
referenced by 
ALLOCATE_PROC 5.1-11 
ALLOCATE_RCB_PROC 3-26 
BID_RSP_PROC 3-35 
CHANGE_SESSIONS_PROC 3-39 
CREATE_TCB_AND PS 3-45 
DEACTIVATE_PENDING_SESSIONS 3-47 
DFC_SEND TO PS 6.1-30 
FIRST_SPEAKER_PROC 3-49 
GET_SESSION PROC 3-52 
PS ABEND PROC 3-54 
PS CREATION _ PROC 3-55 
PS TERMINATION PROC 3-57 
RM_ACTIVATE_SESSION PROC 3-61 
SEND_ATTACH TO PS 3-66 
SEND_DEACTIVATE_SESSION 3-68 
SESSION_ACTIVATED_ALLOCATION 3-70 
SESSION_DEACTIVATED_PROC 3-72 
START_TP_PROC 3-77 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
PS PROCESS _DATA structure 5.0-3, 5.0-24, 
5.1-3 
referenced by 
ACTIVATE_SESSION_PROC 5.4-37 
DEACTIVATE_SESSION_ PROC 5.4-38 
PS 5.0-8 
PS_PROTOCOL_ERROR 5.0-20 
PS profile 
in BIND 4-21 
PS PROTOCOL_ERROR procedure’ 5.0-20 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
CONFIRMED_PROC 5.1-14 
DEQUEUE_FMH7_PROC 5.1-34 
GET_DEALLOCATE_FROM_HS 5.1-35 
GET_END_CHAIN FROM_HS 5.1-36 
PERFORM_RECEIVE_ EC PROCESSING 5.1-38 
PROCESS _FMH7_LOG DATA_PROC 5.1-44 
PROCESS _FMH7_PROC 5.1-46 
RECEIVE_RM_OR_HS_TO PS RECORDS 5.1-51 
SET_FMH7_RC 5.1-59 
WAIT_FOR_CONFIRMED PROC 5.1-61 
WAIT_FOR_RSP_TO_RQ TO SEND PROC 5.1-63 
PS.SPS 
See also presentation services for sync 
point services (PS.SPS) 
See also sync point, manager 
logic 5.3-9, 5.3-16, 5.3-18, 5.3-20, 
5.3-22, 5.3-25, 5.3-30, 5.3-31, 5.3-32, 
5.3-34, 5.3-35 
PS_SPS procedure 5.3-35 
referenced by 
MC_CONFIRM_PROC 5.2-21 
MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
PROCESS ERROR_OR_FAILURE_RC 5.2-31 
PS VERB ROUTER 5.0-16 
PS TERMINATION _PROC procedure 43-57 
referenced by 
PROCESS PS TO_RM RECORD 3-22 


PS Usage field 
in BIND 4-21 
PS_VERB_ROUTER procedure 5.0-16 
referenced by 
PROCESS DATA_INCOMPLETE 5.2-36 
PU (physical unit) 1-3 
peripheral 1-5 
subarea 1-5 
PU type 1-5 
corresponding to node type 1-5 
PURGE_QUEUED_REQUESTS procedure 3-59 
referenced by 
ATTACH_PROC 3-30 
START_TP_PROC 3-77 
purging of chains 2-11, 2-14, 6.1-1 


Le | 


QRI 

See Queued Response indicator (QRI) 
queue 2-4 

See also SEND/RECEIVE process interaction 
QUEUE_ATTACH_PROC procedure 3-60 

referenced by 

ATTACH PROC 3-30 

Queued Response indicator (QRI) 6.2-8 

use 6.1-10, 6.1-12 


iG 


random data 4-22, 4-26 
See also LU-LU verification 
See also session-level security, random 
data 
RCB 
See resource control block (RCB) 
RCB_ALLOCATED_PROC procedure 5.1-48 
referenced by 
ALLOCATE_PROC 5.1-11 
RCB_ALLOCATED structure A-21 
referenced by 
ALLOCATE_PROC 5.1-11 
ALLOCATE_RCB_PROC 3-26 
CREATE_RCB 3-43 
RCB_ALLOCATED_PROC 5.1-48 
TEST_FOR_FREE_FSP_SESSION 3-82 
RCB_DEALLOCATED structure A-21 
referenced by 
END CONVERSATION_PROC 5.1-34¢ 
PROCESS_PS _TO_RM RECORD 3-22 
RCB_ID structure 3-91 
referenced by 
ATTACH_PROC 3-30 
CONNECT_RCB_AND_SCB 3-42 
PS_CREATION_PROC 3-55 
SEND_ATTACH_TO PS 3-66 
SET_RCB_AND SCB_FIELDS 3-75 
RCB_LIST_PTR structure 5.0-24¢ 
RCB structure A-6 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
BID_RSP_PROC 3-35 
BIDDER_PROC 3-37 
COMPLETE_CONFIRM_PROC 5.1-28 
CONFIRM_PROC 5.1-12 
CONFIRMED PROC 5.1-14 
CONNECT_RCB_AND SCB 3-42 
CONVERSATION_FAILURE_PROC 5.1-29 
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CREATE_AND_INIT_LIMITED_MU 5.1-30 
CREATE_RCB 3-43 
DEALLOCATE_ABEND_PROC 5.1-31 
DEALLOCATE_CONFIRM_PROC 5.1-32 
DEALLOCATE_FLUSH_PROC 5.1-33 
DEALLOCATE_PROC 5.1-15 
DEALLOCATION_CLEANUP_PROC 5.0-18 
DEQUEUE_FMH7_PROC 5.1-34¢ 
END_CONVERSATION_PROC 5.1-34 
FLUSH_PROC 5.1-16 
FREE_SESSION PROC 3-50 
FSM_CONVERSATION 5.1-65 
FSM_ERROR_OR_FAILURE 5.1-67 
GET_ATTRIBUTES_ PROC 5.1-17 
GET_DEALLOCATE_FROM_HS 5.1-35 
GET_END_CHAIN_FROM_HS 5.1-36 
GET_SEND_INDICATOR 5.2-44 
GET_SESSION_PROC 3-52 | 
INITIALIZE_ATTACHED_RCB 5.0-20 
MC_ALLOCATE_PROC 5.2-21 
MC_CONFIRM_PROC 5.2-21 
MC_DEALLOCATE_PROC 5.2-23 
MC_POST_ON_RECEIPT_PROC 5.2-25 
MC_PREPARE_TO RECEIVE PROC 5.2-26 
MC_RECEIVE_AND_WAIT_PROC 5. 2-27 
MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
MC_TEST_PROC 5.2-28 
OBTAIN_SESSION_PROC 5.1-37 
PERFORM_RECEIVE EC PROCESSING 5.1-38 
PERFORM_RECEIVE PROCESSING 5.1-40 
POST_ON_RECEIPT PROC 5.1-17 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-42 
PREPARE_TO_RECEIVE PROC 5.1-18 
PROCESS _DATA_COMPLETE 5.2-33 
PROCESS_DATA_INCOMPLETE 5.2-36 
PROCESS _ERROR_OR_FAILURE_RC 5.2-31 
PROCESS _FMH5 5.0-10 

PROCESS _FMH7_LOG_DATA_PROC 5.1-44 
PROCESS _FMH7_PROC 5.1-46 

PROCESS MAPPER_RETURN_CODE 5.2-35 
PROCESS PS _TO_RM_RECORD 3-22 
PROTOCOL_ERROR_PROC 5.2-47 
PS_ABEND_PROC 3-54 
PS_ATTACH_CHECK 5.0-12 

PS CREATION_PROC 3-55 

PS TERMINATION PROC 3-57 

PS _VERB_ROUTER 5.0-16 | 
PURGE_QUEUED_REQUESTS 3-59 
QUEUE_ATTACH_PROC 3-60 
RCB_ALLOCATED_PROC 5.1-48 
RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
RECEIVE_AND_TEST_POSTING 5.1-50 
RECEIVE_AND_WAIT_PROC 5.1-19 
RECEIVE_IMMEDIATE_PROC 5.1-21 
RECEIVE_INFO_PROC 5.2-30 
RECEIVE_PIP_FIELD_FROM_HS 5.0-12 
RECEIVE_RM_OR_HS_TO_PS RECORDS 5.1-51 
REQUEST_TO_SEND_ PROC 5.1-23 
SEND_CONFIRMED_PROC 5.1-53 
SEND_DATA_BUFFER_MANAGEMENT 5.1-54 
SEND_DATA_PROC 5.1-24 | 
SEND_ERROR_DONE_PROC 5.1-55 — 
SEND_ERROR_IN_RECEIVE_STATE 5.1-56 
SEND_ERROR_IN_SEND STATE 5.1-57 
SEND_ERROR_PROC 5.1-25 
SEND_ERROR_TO_HS PROC 5.1-58 
SEND_REQUEST_TO_SEND PROC 5.1-58 
SEND_SVC_ERROR_PURGING 5.2-45 
SESSION_DEACTIVATED PROC 3-72 
SET_FMH7_RC 5.1-59 
SET_RCB_AND_SCB_FIELDS 3-75 
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TEST_FOR_FREE_FSP_SESSION 3-82 
TEST_FOR_RESOURCE_POSTED 5.0-21 
TEST_PROC 5.1-26 
WAIT_FOR_CONFIRMED_PROC 5.1-61 ‘ae 
WAIT_FOR_RSP_TO_RQ_TO_SEND PROC 5.1-63 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-64 
WAIT_PROC 5.0-19 
RCV_PACING_RSP procedure 6.2-29 
referenced by 
TC.RCV 6.2-23 
RCV_STATE_ERROR procedure 6.1-41 
referenced by 
DFC_RCV_FSMS 6.1-25 
RCVD_SVC_ERROR_PURGING procedure 5.2-42 
referenced by 
MC_CONFIRM_PROC 5.2-21 
MC_DEALLOCATE_PROC 5.2-23 
MC_PREPARE_TO_RECEIVE_PROC 5.2-26 
MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
PROCESS _ERROR_OR_FAILURE_RC 5.2-31 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC proce- : 
dure 5.2-41 - 
referenced by Ko 


PROCESS _DATA_INCOMPLETE 5.2-36 
PROCESS ERROR_OR_FAILURE_RC 5.2-31 
READY TO RECEIVE (RTR) 3-11, 6.1-4, 6.1-5, 
- 6.1-8, 6.1-10, 6.1-11, 6.1-14, 6.1-15, 
6.1-17 
reblocking 2-13, 2-17, 2-31 
RECEIVE_AND_TEST_POSTING procedure 5.1-50 
referenced by 
PROCESS_FMH7_LOG_ DATA_ PROC 5.1-44¢ 
RECEIVE _AND_WAIT_PROC 5.1-19 
RECEIVE_PIP_FIELD_FROM_HS 5.0-12 


RECEIVE -AND_WAIT_PROC procedure 5.1-19 fe 
referenced by ; 
GET_SEND_INDICATOR 5.2-44 7 


PS_CONV 5.1-10 
RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
receive check 5.1-9 
RECEIVE_ERROR structure A-10 
referenced by 
DFC_SEND_TO_PS 6.1-30 | 
RECEIVE_RM_OR_HS TO PS RECORDS 5.1-51 
SEND_RSP_TO_RM_OR_PS 6.1-46 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-63“” ~ 
RECEIVE_IMMEDIATE_PROC procedure §.1-21 | 
referenced by 
PS CONV -5.1-10 
RECEIVE_INFO_PROC procedure 5.2-30 
referenced by 
MC_RECEIVE_AND_WAIT_PROC 5.2-27 
MC_TEST_PRGOC 5.2-28 
RECEIVE_PACING procedure 6.2-27 
referenced by 
TC.RCV 6.2-23 
RECEIVE PIP_FIELD_FROM_HS procedure 5.0-12 
referenced by 
PROCESS _FMHS 5.0-10 
RECEIVE RM_OR_HS_TO_PS_RECORDS proce- 
dure 5.1-51 
referenced by 
CONFIRM_PROC 5.1-12 
CONFIRMED_PROC 5.1-14 
DEALLOCATE_ABEND_PROC 5.1-31 
DEALLOCATE_CONFIRM_PROC 5.1-32 


' 
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DEALLOCATE_FLUSH_PROC 5.1-33 a 
FLUSH_PROC 5.1-16 q 
POST_ON_RECEIPT_PROC 5.1-17 ~—-" 


PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-42 


ee eet 
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RECEIVE_AND_TEST_POSTING 5.1-50 
RECEIVE _AND_WAIT_PROC 5.1-19 
RECEIVE IMMEDIATE PROC 5.1-21 
REQUEST_TO_SEND_PROC 5.1-23 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_IN_SEND_STATE 5.1-57 
SEND_ERROR_PROC 5.1-25 
TEST_PROC 5.1-26 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
WAIT_PROC 5.0-19 
RECEIVED_INFO structure A-7 
receiving data 2-31 
recovery 
See errors and failures 
remote, role of LU and TP 2-5, 2-40 
reply in HDX-FF protocol 
See send/receive mode, half-duplex 
flip-flop (HDX-FF ) 
REPLY_TO_BID procedure 6.1-42 
Request Commit 
See sync point, commands, Request Commit 
request control mode 6.2-7 
See also control mode 
immediate request mode 6.1-10 
request/response correlation 6.1-1, 6.1-9 
request/response header (RH) 2-15, 2-17, 
2-19, 2-30 
relationship to verbs 2-18 
session control 6.2-5 
request/response units (RUs) 2-15 
maximum RU size 6.2-7 
maximum size 2-8, 2-17, 2-30, 2-40 
REQUEST_TO_SEND_PROC procedure 5.1-23 
referenced by 
MC_REQUEST_TO_SEND_PROC 5.2-37 
PS_CONV 5.1-10 
REQUEST_TO_SEND structure A-10 
referenced by 
DFC_SEND_TO_PS 6.1-30 
RECEIVE _RM_OR_HS_TO_ PS_ RECORDS 5.1-51 
TRY_TO_RCV_SIGNAL 6.1-23 
WAIT_FOR_CONFIRMED_PROC 5.1-61 
WAIT _ FOR_RSP _TO_ RQ_TO_SEND_PROC 5.1-63 
RESERVE_CONSTANT_BUFFERS procedure 4-84 
‘referenced by 
PREPARE_TO_SEND_BIND 4-73 
PROCESS_BIND_RQ 4-76 
RESERVE_VARIABLE_BUFFERS procedure 4-84 
referenced by 
PROCESS BIND_RQ 4-76 
PROCESS BIND RSP 4-78 
RESET_SESSION_LIMIT_PROC procedure 5.4-35 
referenced by 
PS_COPR 5.4~-33 
RESET_SESSION_LIMIT verb 5.4~-6, 5.4-22 
processing | by PS.COPR 5.4-21 
all mode names 5.4-6, 5.4-28, 5.4-29, 
5.4-31 
FORCE parameter 5.4-21 
parallel-session mode name 5.4-31 
single-session mode name 5.4-26 
SNASVCMG mode name 5.4-26 
resource 2-3, 2-43 
dynamic 2-40 
local 2-4 
network, LU-accessed 2-3, 2-4, 2-36, 
2-40, 2-43, 5.4-1, 5.4-3, 5.4-5 
local LU 5.4-5 
mode 5.4-5 
partner LU 5.4-5 
transaction program 5.4-5 
posting 5.0-7, 5.1-7 
protected 2-4, 2-37 


resource control block (RCB) 5.2-4, 2-40, 
3-4, 5.0-3, 5.1-4, 5.2-4, 5.3-7, 5.3-8, 
5.3-18, 5.3-20 

resource ID 2-6 

resources manager (RM) 2-38), 3-1 

function summary 2-35, 3-2 

process 2-43 

protocol boundary ° 2-47, 3-2 
resources, local : 

See sync point, local resources 

RESPONSE_CODE structure 3-92 

referenced by 
START_TP_PROC 3- -77 
response control mode, 6 .2-7 
See also control mje 
immediate response mode 6.1-10 
response correlation 2-31 
response to chain 
See request/response units (RUs) 
responsible parameter 3-17 
See also session, deactivation, responsi- 
bility 
negotiation by CNOS 5.4-31 
RESULT_CHECK_ALLOCATE procedure 5.4-52 
referenced by 
SOURCE_CONVERSATION 5.4- 50 

RESULT_CHECK_RECEIVE. _ COMMAND proce- 

dure 5.4-62 
referenced by 
TARGET_COMMAND_CONVERSATION 5.4-61 
RESULT_CHECK_RECEIVE DEALLOCATE proce- 
dure 5.4-55 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_RECEIVE_REPLY procedure 5.4-54 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_RECEIVE —SEND procedure 5.4-62 
referenced by 
TARGET _. COMMAND: CONVERSATION 5.4-61 
RESULT_CHECK_SEND_COMMAND procedure 5.4-53 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_SEND_REPLY procedure 5.4-66 
referenced by , 
TARGET_REPLY_CONVERSATION 5.4-65 
resync service transaction program 
See sync point, resynchronization 
resynchronization 
See sync point 
RH pithy 
See request/respofina header (RH) 


RM : 
See resources manager (RM) 
RM_ACTIVATE_SESSION_PROC procedure 3-61 
referenced by 
PROCESS_PS_TO_RM_RECORD 3-22 
RM_ACTIVATE_SESSION structure A-16 
referenced by 
ACTIVATE_SESSION_PROC 5.4-37 
DEACTIVATE_PENDING_SESSIONS 3-47 
PROCESS PS TO_RM_RECORD 3-22 
RM_ACTIVATE_SESSION PROC 3-61 
SESSION_DEACTIVATED_PROC 3-72 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
RM_CREATE_PARMS structure A-27 
referenced by 
SM 4-48 
RM_CREATED 4-8 


-RM_CREATED structure gift, 27 


referenced by fi 
SM 4-48 
RM_DEACTIVATE _SESSION_ PROC procedure 3-62 
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K-22 


referenced by 
PROCESS PS _TO_RM_RECORD 3-22 
RM_DEACTIVATE_SESSION structure A-17 
referenced by 
DEACTIVATE_SESSION_PROC 5.4-38 
PROCESS_PS TO_RM_RECORD 3-22 
RM_DEACTIVATE_SESSION_PROC 3-62 
SEND_BIS_RQ 3-67 
SHOULD_SEND_ BIS 3-76 
RM_HS_CONNECTED structure A-18 
referenced by 
HS 6.0-3 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
RM process 3-19 
referenced by 
ACTIVATE_SESSION_PROC 5.4-37 
ALLOCATE_PROC 5.1-11 
BUILD_AND_SEND_ACT_SESS_RSP_NEG 4-58 
BUILD_AND SEND_ACT_SESS _RSP_POS 4-58 
BUILD_AND_SEND_SESS_ACTIVATED 4-63 
BUILD AND SEND SESS DEACTIVATED 4-64 
CHANGE_ACTION 5.4-44 
DEACTIVATE_SESSION_PROC 5.4-38 
DEALLOCATION_CLEANUP_PROC 5.0-18 
END_CONVERSATION_PROC 5.1-34 
GENERATE_RM_PS_ INPUTS 6.1-36 


HS 6.0-3 
OBTAIN_SESSION PROC 5.1-37 
PS 5.0-9 

PS _PROTOCOL_ERROR 5.0-20 
SM 4-48 


WAIT_FOR_RM_REPLY 5.1-62 
RM_SESSION_ACTIVATED structure A-22 
referenced by 
ACTIVATE_SESSION_PROC 5.4-37 
DEACTIVATE_PENDING_SESSIONS 3-47 
RM_ACTIVATE_SESSION_PROC 3-61 
SESSION_DEACTIVATED_ PROC 3-72 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
route 2-40 
routing and checking logic, representation 
within the formal description 1-1 
RSP_TO_REQUEST_TO_SEND structure A-11 
referenced by 
DFC_SEND_TO PS 6.1-30 
RECEIVE RM_OR_HS_TO_PS_RECORDS 5.1-51 
SEND_RSP_TO_RM OR_PS 6.1-46 
WAIT_FOR_RSP_TO_RQ_TO_SEND PROC 5.1-63 
RSP(BIND) 4-24 
RSP(UNBIND) 4-28 
RTR (READY TO RECEIVE) 6.1-17 
RTR_RQ_PROC procedure 3-63 
referenced by 
PROCESS _HS_TO_RM_RECORD 3-20 
RTR_RQ structure A-12 
referenced by 
DFC_SEND_FROM_RM 6.1-21 
FREE_SESSION_PROC 3-50 
GENERATE_RM_PS_INPUTS 6.1-36 
PROCESS _HS_TO_RM_RECORD 3-20 
RTR_RQ_PROC 3-63 
SEND_RTR_PROC 3-69 
RTR_RSP_PROC procedure 3-64 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-20 
RTR_RSP structure A-13 
referenced by } 
GENERATE_RM_PS_INPUTS 6.1-36 
PROCESS _HS_TO_RM_RECORD 3-20 
RTR_RQ_PROC 3-63 
RTR_RSP_PROC 3-64 
SEND_RSP_TO_RM_OR_PS 6.1-46 
RU 
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See request/response units (RUs) 
RU parameters -_ 
implementation-dependent 4-18 \ 
installation-specified 4-18 
specification of 4-18 
rule 1 (conditional termination) 
See bracket, bracket termination rule 


[| 


SCB structure A-8 
referenced by 

ATTACH_PROC 3-30 
BID_RSP_PROC 3-35 
CONNECT_RCB_AND_SCB 3-42 
CREATE_SCB 3-44 
DEACTIVATE_FREE_SESSIONS 3-46 
FIRST_SPEAKER_PROC 3-49 
FREE_SESSION_PROC 3-50 a, 
GET_SESSION_PROC 3-52 Lo 
PROCESS_HS_TO_RM_RECORD 3-20 ed 
PROCESS PS TO_RM_RECORD 3-22 
PS ABEND PROC 3-54 
PS CREATION PROC 3-55 
PURGE_QUEUED_REQUESTS 3-59 
QUEUE_ATTACH_PROC 3-60 
RM_DEACTIVATE_SESSION_ PROC 3-62 
RTR_RQ_PROC 3-63 
SECURITY_PROC 3-65 
SEND_ATTACH_TO_PS 3-66 
SEND_DEACTIVATE_SESSION 3-68 


SEND_RTR_PROC 3-69 a 
SESSION_ACTIVATED_ALLOCATION 3-70 4 ; 
SESSION_DEACTIVATED_PROC 3-72 ee 


SET_RCB_AND SCB FIELDS 3-75 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
TEST_FOR_FREE_FSP_SESSION 3-82 
secondary LU (SLU) 2-33 
See also session, activation polarity 
secondary LU name 
in BIND 4-23 
security 2-9, 2-12 
See also conversation-level security 
See also session cryptography 


See also session-level security | a, 
security downgrade 4 ' 
See conversation-level security a. 


Security FM header 4-18 
See also FM header, type 12 (Security) 
SECURITY_PROC procedure 3-65 
referenced by 
PROCESS _HS_TO_RM_RECORD 3-20 
segment reassembly 6.2-12 
SEGMENT_REASSEMBLY procedure 6.2-28 
referenced by 
TC.RCV 6.2-23 
SEND_ACTIVATE_SESSION procedure 3-65 
referenced by 
ACTIVATE_NEEDED_ SESSIONS 3-24 
GET_SESSION PROC 3-52 
RM_ACTIVATE_SESSION PROC 3-61 
SEND_ATTACH_TO_PS procedure 3-66 
referenced by 
ATTACH _PROC 3-30 
SEND_BID_POS_RSP procedure 6.1-42 
referenced by — 
SEND_RSP_TO_RM_OR_PS 6.1-46 | 
SEND_BIS procedure 3-66 
referenced by 
DEACTIVATE_FREE_SESSIONS 3-46 
FREE_SESSION_PROC 3-50 


GET_SESSION_PROC 3-52 
RTR_RQ_PROC 3-63 
RTR_RSP_PROC 3-64 
SEND_BIS REPLY procedure 3-67 
referenced by 
CHECK_FOR_BIS_ REPLY 3-40 
SEND_BIS 3-66 
SEND_BIS_RQ procedure 3-67 
referenced by 
BIS_RACE_LOSER 3-38 
RM_DEACTIVATE_SESSION_PROC 3-62 
SEND_BIS 3-66 
SEND_BUFFER structure 5.2-48 
referenced by 
MC_SEND_DATA_PROC 5.2-38 
SEND_CONFIRMED_PROC procedure 5.1-53 
referenced by 
CONFIRMED_PROC 5.1-1% 
SEND_DATA_BUFFER_MANAGEMENT procedure 5.1-54 
referenced by | 
ATTACH_ERROR_PROC 5.0-15 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-29 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_DONE_ PROC 5.1-55 
SEND_DATA_PROC procedure 5.1-24 
referenced by 
MC_SEND_DATA_PROC 5.2-38 
PS_ CONV 5.1-10 
SEND_SVC_ERROR_PURGING 5.2-45 
SEND_DEACTIVATE_SESSION procedure 3-68 
referenced by 
ATTACH_PROC 3-30 
BID_PROC 3-33 
BID_RSP_PROC 3-35 
DEACTIVATE_PENDING_SESSIONS 3-47 
FREE SESSION_PROC 3-50 
FSM_BIS_BIDDER 3-87 
FSM BIS FSP 3-88 
PROCESS _PS_TO_RM_RECORD 3-22 
RM_DEACTIVATE_SESSION_PROC 3-62 
RTR_RQ PROC 3-63 
SECURITY_PROC 3-65 
SEND_ERROR_DONE_PROC procedure 5.1-55 
referenced by 
SEND_ERROR_IN_SEND_STATE 5.1-57 
SEND_ERROR_PROC 5.1-25 
WAIT _FOR_SEND_ERROR_DONE_PROC 5.1-64 
SEND_ERROR_IN RECEIVE STATE procedure 5.1-56 
referenced by 
SEND_ERROR_PROC 5.1-25 
SEND_ERROR_IN_SEND_STATE procedure 5.1-57 
referenced by 
SEND_ERROR_PROC 5.1-25 
SEND_ERROR_PROC procedure 5.1-25 
referenced by 
MC_SEND_ERROR_ PROC 5.2-40 
PS CONV 5.1-10 
SEND_SVC_ERROR_PURGING 5.2-45 
SEND_ERROR structure A-14¢ 
SEND_ERROR_TO_HS_PROC procedure 5.1-58 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
DEALLOCATE_ABEND_PROC 5.1-31 
SEND_ERROR_IN_RECEIVE_STATE 5.1-56 
SEND_ERROR_PROC 5.1-25 
SEND_FMD_MU procedure 6.1-43 
referenced by 
DFC_SEND_FROM_PS 6.1-20 
DFC_SEND_FROM_RM 6.1-21 
SEND_MU procedure 6.2-20 
referenced by 
DFC_SEND_FSMS 6.1-27 
TC.EXCHANGE_CRV 6.2-15 
SEND_PACING procedure 6.2-21 


referenced by 
SEND_TO_PC 6.2-22 
SEND_PARM structure A-32 
send/receive concurrency 2-6 
send/receive mode 
full-duplex (FDX) 
half-duplex flip-flop (HDX-FF) 6.1-1, 
6.1-4, 6.1-11 
SEND/RECEIVE process interaction 2-40 
send/receive state of conversation 2-6, 
2-30, 2-32 
See also half-duplex flip-flop 
send/receive mode 
SEND_REQUEST_TO_SEND_PROC procedure 5.1-58 
referenced by 
REQUEST_TO_SEND_PROC 5.1-23 
SEND_RSP_IF_REQUIRED procedure 6.1-4%4¢ 
referenced by 
DFC_RCV_FSMS 6.1-25 
SEND_RSP_MU procedure 6.1-45 
referenced by 
DFC_RCV 6.1-24 
DFC_SEND_FROM_PS 6.1-20 
SEND_RSP_IF_REQUIRED 6.1-44 
SEND_RSP_TO_RM_OR_PS procedure 6.1-46 
referenced by 
DFC_RCV_FSMS 6.1-25 
SEND_RTR_PROC procedure 3-69 
referenced by 
PROCESS_INITIATOR_TO_RM_RECORD 3-20 
SEND_RTR structure A-20 
referenced by 
PROCESS_INITIATOR_TO_RM_RECORD 3-20 
SEND_RTR_PROC 3-69 
SEND_SVC_ERROR_PURGING procedure 5.2-45 
referenced by 
PROCESS_DATA_COMPLETE 5.2-33 
PROCESS MAPPER_RETURN_CODE 5. 2-35 
SEND_TO_PC procedure 6.2-22 
referenced by 
BUFFERS _RESERVED_PROCESSING 6.2-31 
RCV_PACING RSP 6.2-29 
SEND_MU 6.2-20 
sending data 2-30 
SENSE_CODE structure 3-92 
referenced by 
SEND_DEACTIVATE_SESSION 3-68 
sense data 
in FMH-7 2-19 
SENSE_DATA structure 5.0-25 
referenced by 
ATTACH_ERROR_PROC 5.0-15 
PROCESS FMH5 5.0-10 
PS_ATTACH_CHECK 5.0-12 
PS PIP CHECKS 5.0-13 
PS PROTOCOL_ERROR 5.0-20 
RECEIVE_PIP_FIELD_FROM_HS 5.0-12 
sequence flows 
abbreviations 2-48 
basic conversation 2-48 
conventions 2-48 
external protocol boundaries 2-18 
application-detected error cases 2-24 
error-free cases 2-19 
REQUEST_TO_SEND case 2-24 
internal protocol boundaries 2-48 
notations 2-48 
session activation and deactivation 2-50; 
2-52 
sequence numbers and IDs 
use in data flow control 6.1-5 
sequence numbers, TH 2-15, 2-30, 2-31, 6.2-6 
checking 6.2-1 
expedited flow 6.2-6 
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identifiers 6.2-6 
initialization 6.2-6 
normal flow 6.2-6 
see='transmission control (TC) 
wrapping 6.2-6 
service transaction program 2-3, 2-36 
See also transaction program 
CNOS 2-3 
DIA 2-3 
resync (X'‘'06F2‘ ) 
See sync point, resynchronization 
resynchronization 2-3 | 
SNA/DS 2-3) 2-7 
SESSEND_SIGNAL 4-10 
SESSEND_SIGNAL structure A-24 
referenced by 
BUILD _AND SEND _SESSEND_SIG 4-64 
PROCESS CINIT_SIGNAL 4-79 
session 2-1, 2-3 
activation 2-8, 2-33» 2-365) 2-435 2-44), 
3-15, 5.4-4, 5.4-8 
LU-LU 4-19 
newly active session 2-33 
relation to PS.COPR 5.4-8 
activation polarity 2-8 
allocation to conversation 2-7, 2-32, 3-5 
session selection 2-7, 2-32, 3-6 
contention polarity 2-7, 2-32, 5.4-3; 
5.4-8 
See also SESSION LIMITS», minimum con- 
tention winner 
processing by PS.COPR--mode name 
SNASVCMG session 5.4-26 
processing by PS.COPR--single ses- 
sion 5.4-26 
cryptography 
See cryptography > session-level 
cryptography 
deactivation 2-8, 2-31, 2-34) 2-36, 2-43, 
5.4-4, 5.4-8 
LU-LU 4-2 
operator controlled 2-34 
relation to PS.COPR 5.4-8, 5.4-26 
responsibility 5.4-4, 5.4-8, 5.4-22,; 
5.4-29 
specific session 2-34 
identification 5.4-3 
See also identification of session 
initiation 2-8, 2-33, 5.4-4 
multiplicity 2-7 
parallel 2-1, 2-7, 5.4-3, 5. 4-22 
shutdown 2-8) 2-34, 2-43, 5.4-4, 5.4-8 
single 2-7, 5.4-3, 5.4-22 
state 2-30 
termination 2-8, 4-2, 5.4-4 
SESSION_ACTIVATED 4-6 
SESSION_ACTIVATED_ALLOCATION procedure 3-70 
referenced by 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
SESSION_ACTIVATED_PROC procedure 3-70 
referenced by 
PROCESS _ SM_TO_RM_RECORD 3-23 
SESSION_ACTIVATED structure A- 14 
referenced by 
BUILD AND SEND _SESS_ACTIVATED 4-63 
PROCESS_SM_TO_RM_RECORD 3-23 
SESSION_ACTIVATED_PROC 3-70 
SESSION_ACTIVATION_POLARITY procedure 3-71 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-24 
GET_SESSION_PROC 3-52 
RM_ACTIVATE_SESSION_PROC 3-61 
SESSION_ALLOCATED structure A-22 
referenced by 
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BID_RSP_PROC 3-35 
CHANGE_SESSIONS PROC 3-39 
FIRST_SPEAKER_PROC 3-49. 
GET_SESSION_PROC 3-52 
OBTAIN_SESSION_PROC 5.1-37 
SEND_DEACTIVATE_SESSION 3-68 
SESSION_ACTIVATED_ALLOCATION 3-70 
SESSION _DEACTIVATED_PROC 3-72 
SUCCESSFUL_SESSION_ACTIVATION 3-81 
UNSUCCESSFUL_SESSION_ACTIVATION 3-83 
session control block (SCB) 3-4 
session control RUs 2-17, 4-19 
BIND 4-19 
CRV 6.2-3, 6.2-5 
RH 6.2-5 
RSP( BIND ) 
RSP (UNBIND ) 
TH 6.2-5 
UNBIND 4-27 
session counts 5.4-4, 5.4-8 
See also session limits 
relationship to CNOS 5.4-6, 5.4-29 
termination count 3-17, 5.4-4, 5.4-8 
session cryptography 2-9, 2-10, 2-30, 2-31; 
2-40 
key 2-10 
session seed 2-10 
verification 2-33 
SESSION_DEACTIVATED 4-6 
SESSION_DEACTIVATED_PROC procedure 3-72 
referenced by 
PROCESS_SM_TO_RM_RECORD 3-23 
PS ABEND PROC 3-54 
PURGE_QUEUED_REQUESTS 3-59 
SEND_DEACTIVATE_SESSION 3-68 
SESSION_DEACTIVATED structure A-14 
referenced by 
BUILD_AND_SEND_SESS_DEACTIVATED 4-64 
PROCESS SM_TO_RM_RECORD 3-23 
PS ABEND PROC 3-54 
PURGE_QUEUED_ REQUESTS 3-59 
SEND_DEACTIVATE_SESSION 3-68 
SESSION_DEACTIVATED_PROC 3-72 
SESSION_DEACTIVATION_POLARITY procedure 3-74 
referenced by 
BIS_RACE_LOSER 3-38 
DEACTIVATE_FREE_SESSIONS 3-46 
DEACTIVATE_PENDING_SESSIONS 3-47 
SHOULD_SEND_BIS 3-76 
SESSION_INFORMATION structure A-32 
referenced by 
CREATE_SCB 3-44 
SUCCESSFUL_SESSION_ACTIVATION 3-80 
session-level pacing 2-8) 2-31, 6.2-1, B-1; 
B-2, B-3 
See also pacing 
adaptive pacing 4-21, 4-24, 4-25, 6.2-8 
algorithms 6.2-8 
deadlock 6.2-8 
fixed pacing 6.2-8 
IPM 6.2-8 
IPR 6.2-8 
pacing count 6.2-7 
pacing queue 6.2-8 
parameter set up 6.2-3 
PI 6.2-7, 6.2-8 | 
queued response indicator (QRI) 
response 2-8, 2-31 
stages 6.2-7 
window 2-8, 2-31 
Window size 2-35 2-8, 2-31; 2-40, 6.2-7 


4-24 
4-28 


6.2-8 


3-15 
DES (Data Encryption Standard) 2-9 


f 
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session-level security 2-9, 2-33, 2-35, Ao 


‘Am, 


enciphered data 2-9, 2-33 
FMH~-12 
See FM header, type 12 (Security) 
LU-LU password 2-9, 2-33 
LU-LU verification 2-9, 2-35, 3-2, 3-15 
LU-LU verification sequence 2-9 
physical security 2-10 
random data 2-9, 2-33 
SESSION_LIMIT_DATA_LOCK_MANAGER proce- 
dure 5.4-67 
referenced by 
PROCESS _SESSION_LIMIT_PROC 5.4-58 
SOURCE_SESSION_LIMIT_PROC 5.4-46 


session limits 2-8, 3-15, 3-16) 5.4-4, 5.4-8 


automatic activation 2-8) 2-34, 3-16, 
3-17, 5.4-4, 5.4-8 
initialization 2-8, 2-33, 2-36, 2-43, 
5.4-4 
LU-mode 2-8, 5.4-4, 5.4-8 
minimum contention winner 2-8, 3-16; 
5.4-4, 5.4-8, 5.4-22, 5.4-26 
negotiation by CNOS 5.4-7, 5.4-29 
reset 2-8, 2-34, 2-43, 5.4-4 
total LU-LU 2-8, 5.4-4 
session manager (SM) 4-1 
creation 2-29, 2-43 
formal description 4-47 
function summary 2-35 
general description 4-1 
process 2-43 
protocol boundaries 2-46, 2-47 
protocol boundary 4-4 
with address space manager (ASM) 4-11 
with half session (HS) 4-7 
with node-operator (NOF) 4-8 
with resources manager (RM) 4-5 
with session services (SS) 4-9 
session outage 3-18 
See also errors and failures 
session outage notification (SON) 2-11, 
2-34, 4-3 
See also errors, conversation failure 
CNOS recovery 5.4-21 
See also error recovery, CNOS, conver- 
sation failure 
session pool 2-7 
See also session, allocation to conversa- 
tion 
SESSION _ROUTE_INOP 4-11 
SESSION_ROUTE_INOP structure A-24¢ 
referenced by 
FSM_STATUS 4-87 
PROCESS _RECORD_FROM_ASM 4-51 
PROCESS SESSION_ROUTE_INOP 4-83 
session seed 6.2-3 
SESSST_SIGNAL 4-10 
SESSST_SIGNAL structure A-24 
referenced by 
BUILD_AND_SEND_SESSST_SIG 4-65 
SET_FMH7_RC procedure 5.1-59 
referenced by 
PROCESS_FMH7_LOG_DATA_PROC 5.1-44 
PROCESS _FMH7_PROC 5.1-4%6 
SET_RCB_AND_SCB_FIELDS procedure 3-75 
referenced by 
BID_RSP_PROC 3-35 
FIRST_SPEAKER_PROC 3-49 
SESSION_ACTIVATED_ALLOCATION 3-70 
TEST_FOR_FREE_FSP_SESSION 3-82 
sharing sessions 
See session, allocation to conversation 
SHOULD_SEND_BIS procedure 3-76 
referenced by 
FREE SESSION PROC 3-50 


RTR_RQ_PROC 3-63 
RTR_RSP_PROC 3-64 
shutdown of LU 2-43, 2-45 
shutdown of sessions 
See session, shutdown 
SIG (SIGNAL) 2-24, 6.1-17 
SIGNAL (SIG) 6.1-4, 6.1-5, 6.1-7, 6.1-8, 
6.1-14, 6.1-15, 6.1-17 
SIGNAL_STATUS procedure 6.1-47 
referenced by 
TRY_TO_RCV_SIGNAL 6.1-23 
single-instance transaction program 
See transaction program instance (TP); 
limit 
Single session 
See session, single 
single-session LU 2-7 
See also session, single 
SLU 
See secondary LU (SLU) 
SLU name 
in BIND 4-23 
SM 
See session manager (SM) 
SM_CREATE_PARMS structure A-27 
referenced by 
SM 4-48 
SM process 4-48 
referenced by : 
ACTIVATE_NEEDED_SESSIONS 3-24 
HS 6.0-3, 6.0-4% 
PS _ABEND_PROC 3-54 
PURGE_QUEUED_REQUESTS 3-59 
SEGMENT_REASSEMBLY 6.2-28 
SEND_ACTIVATE_SESSION 3-65 
SEND_DEACTIVATE_SESSION 3-68 
SNA-defined mode name for CNOS 
(SNASVCMG) 2-43, 5.4-5, 5.4-22, 5.4-28 


SNA Distribution Services (SNA/DS) 2-7, 2-36 


SNA/DS 

See SNA Distribution Services (SNA/DS) 
SNA network, definition of 1-3 
SNA node 1-3, 1-4¢ 

See also node 
SNA product node 1-3, 1-4 

See also node 
SNASVCMG 

See SNA-defined mode name for CNOS 

( SNASVCMG )} 

SNF structure A-33 
SON 

See session outage notification (SON) 


SOURCE_CONVERSATION_CONTROL procedure 5.4-49 


referenced by 
SOURCE_SESSION LIMIT_PROC 5.4-46 
SOURCE_CONVERSATION procedure 5.4-50 
referenced by 
SOURCE_CONVERSATION_CONTROL 5.4-49 
SOURCE_SESSION_LIMIT_PROC procedure 5.4-46 
referenced by 
CHANGE_SESSION_LIMIT_PROC 5.4-36 
INITIALIZE_SESSION_LIMIT_PROC 5.4-34¢ 
RESET_SESSION_LIMIT_PROC 5.4-35 
source, role of TP and LU 2-5, 5.4-3 
space (X'40') characters 
trailing 
in LU name comparison 5.4-20 
SSCP (system services control point) 1-3 
START_TP_PROC procedure 3-77 
referenced by 
PROCESS_INITIATOR_TO_RM_RECORD 3-20 
PS ABEND_PROC 3-54 
START_TP_REPLY structure A-20 
referenced by 


Index X-25 


X-26 


PS TERMINATION PROC 3-57 
PURGE_QUEUED_REQUESTS 3-59 
START_TP_PROC 3-77 
START_TP_SECURITY_VALID procedure 3-79 
referenced by 
START_TP_PROC 3-77 
START_TP structure A-19 
referenced by 
CREATE_TCB_AND PS 3-45 
PROCESS INITIATOR_TO_RM_RECORD 3-20 
PROCESS START_TP 5.0-11 
PS 5.0-8 
PS ABEND_PROC 3-54 
PS TERMINATION PROC 3-57 
PURGE_QUEUED_REQUESTS 3-59 
START_TP_PROC 3-77 
START_TP_SECURITY_VALID 3-79 
startup of LU) 2-43 
state name N-1 
state transition N-1 
state-transition matrix N-1 
action codes 
calling result N-1 
calling N-1 
input signal N-1l 
next-state indicator N-1 
initialization N-1 
inputs to N-1 
output actions N-1 
state name N-1 
state transitions N-1 
state, FSM N-l 
statements 
Call 
finite-state machines N-1 
stray responses 6.1-5 
STRAY_RSP procedure 6.1-48 
referenced by 
DFC_RCV 6.1-24 
stray SIGNALS 6.1-5 
subarea 1-4 
subarea LU 1-5 
subarea node 1-4 
See also node 
subarea node to peripheral node communcation 
See peripheral node to subarea node commu- 
nication 
subarea node to subarea node communi- 
cation 2-1 
subarea PU 1-5 
sublayers of PS 2-4 
SUCCESSFUL_SESSION_ACTIVATION procedure 3-80 
referenced by 
ACTIVATE_SESSION_RSP_PROC 3-25 
SESSION_ACTIVATED_PROC 3-70 
SVCMG_VERB_PARAMETER_CHECK procedure 5.4-44 
referenced by 
LOCAL_SESSION_LIMIT_PROC 5.4-42 
sync point 2-4, 2-11, 2-12, 2-37, 5.3-1 
back-out 2-38 
commands 5.3-2 
Backed Out 5.3-3, 5.3-16, 5.3-17, 
5.3-32, 5.3-41 
Committed 5.3-3, 5.3-9, 5.3-35, 5.3-36 
Compare States 5.3-2, 5.3-7, 5.3-8, 
5.3-9, 5.3-15, 5.3-18, 5.3-20, 5.3-22;5 
5.3-25, 5.3-32, 5.3-33, 5.3-34 
Exchange Log Name 5.3-2, 5.3-18, 
5.3-31, 5.3-33, 5.3-34 
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Forget 5.3-3, 5.3-9, 5.3-32, 5.3-35, 


5.3-36 -_ 
Heuristic Mixed 5.3-26, 5.3-35, 5.3-37 
implied Forget 5.3-5, 5.3-12, 5.3-30 oe 
Prepare 5.3-3, 5.3-9, 5.3-22, 5.3-35 
Request Commit 5.3-3, 5.3-9, 5.3-22,; 

5.3-35, 5.3-36 

committed 2-38 
conversation resources 5.3-7 
conversation resource protection manag- 

er 5.3-7 

data-base update Sens istency 2-37 
errors during sync point 5.3-9, 5.3-15; 
5.3-20, 5:3-22, 5.3-24, 5.3-32, 5.3-34 
failures and recovery 5.3-24, 5.3-25, 
5.3-30, 5.3-31, 5.3-32, 5.3-33, 5.3-41 
relationships among 5.3-2 
flows 5.3-37, 5.3-39, 5.3-40, 5.3-G1 
general case 5.3-11 
last resource optimization 5.3-5, 
5.3-9, 5.3-13, 5.3-20, 5.3-25, 5.3-32; 
5.3-36, 5.3-38 ; 
no changes optimization 5.3-5, B.3-14,/ 
5.3-36, 5.3-39 \ 
function shipping 5.3-8 
heuristic decision 5.3-15, 5.3-16, 
5.3-18, 5.3-22, 5.3-24, 5.3-25, 5.3-30, 
5.3-32, 5.3-34, 5.3-37 

and lock manager 5.3-16, 5.3-30 
local resources 5.3-5, 5.3-7, 5.3-18, 
5.3-20 
log 5.3-3, 5.3-6, 5.3-18, 5.3-31 

See also log manager 

forcing 5.3-7, 5.3-8 
logging 2-37, 2-38 


logical unit of work 2-38 
manager 5.3-3, 5.3-25, 5.3-30, 5.3-32, = 
5.3-35 ee 
operator messages 5.3-25, 5.3-30 
phases 
See also sync point, commands 
classification 5.3-9 
presentation services header 
See presentation services (PS) headers 
protection manager 2-38, 5.3-6, 5.3-15, 
5.3-18, 5.3-20 
protocol 2-38 
resynchronization 2-38, 5.3-2, 5.3-15, = 
5.3-16, 5.3-18, 5.3-19, 5.3-20, 5.3-22, / 
5.3-25, 5.3-30, 5.3-31, 5.3-32, 5.3-33, \ 
5.3-34 ae 
roles 5.3-2, 5.3-18, 5.3-22, 5.3-25 
agent 5.3-2, 5.3-3, 5.3-18, 5.3-22 
cascaded agent 5.3-2, 5.3-3, 5.3-18, 
5§.3-20, 5.3-28, 5.3-32 
initiator 5.3-2,; 5.3-3)>) 5.3-9> 5.3-18,; 
5.3-32 
structure 2-38 
synchronization point 2-38 
unit of work 
See sync point, logical unit of work 


Sold cie* 


synchronized unit of work 


See sync point, logical unit of work 


synchronous transfer 2-6, 2-36 
SYNCPT 


See sync point 


system services control point (SSCP) 


See SSCP (system services control point) 
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TARGET_COMMAND_CONVERSATION procedure 5.4-61 


referenced by 


PROCESS _SESSION_LIMIT_PROC 5.4-58 
TARGET_REPLY_CONVERSATION procedure 5.4-65 


referenced by 


PROCESS_SESSION_LIMIT_PROC 5.4-58 


target, role of TP and LU 2-5, 5.4-3 
TC 
See transmission control (TC) 
TC .BIU_RCV_CHECKS procedure 6.2-25 
referenced by 
TC.RCV 6.2-23 
TC.BUILD_CRV procedure 6.2-17 
referenced by | 
TC.EXCHANGE_CRV 6.2-15 
TC .CRV_FORMAT_CHECK procedure 6.2-18 
referenced by 
TC.EXCHANGE_CRV 6.2-15 
TC.DECIPHER_RU procedure 6.2-32 
referenced by 
TC.RCV 6.2-23 
TC.EXCHANGE_CRV procedure 6.2-15 
referenced by 
TC.INITIALIZE 6.2-13 
TC.INITIALIZE procedure 6.2-13 
referenced by 
HS 6.0-3 
TC.RCV procedure 6.2-23 
referenced by 
PROCESS _LU_LU SESSION 6.0-5 
TC.SEGMENT_RCV_CHECKS procedure 6.2-24 
referenced by 
TC.RCV 6.2-23 
TCB 
See transaction control block (TCB) 
TCB_ID structure 3-91 
referenced by 
ATTACH_PROC 3-30 
PS CREATION_PROC 3-55 
SEND_ATTACH_TO_PS 3-66 
TCB_LIST_PTR structure 5.0-24 
TCB structure A-9 
referenced by 
COMPLETE_LUW_ID 3-41 
CREATE_RCB 3-43 
CREATE TCB_AND PS 3-45 
DEALLOCATION_CLEANUP_PROC 5.0-18 
GET_TP_PROPERTIES PROC 5.0-18 
PROCESS _ FMH5 5.0-10 
PROCESS START_TP 5.0-11 
PS 5.0-8 
PS ABEND PROC 3-54 
PS_ATTACH_CHECK 5.0-12 
PS CREATION_PROC 3-55 
PS_PIP_CHECKS 5.0-13 
PS TERMINATION PROC 3-57 
PS_VERB_ROUTER 5.0-16 
RCB_ALLOCATED_PROC 5.1-48 
WAIT_PROC 5.0-19 
terminal 2-1, 2-4 
See also resource, local 
TERMINATE_PS structure A-17 
referenced by 
DEALLOCATION_CLEANUP_PROC 5.0-18 
PROCESS PS _TO_RM_RECORD 3-22 
PS TERMINATION PROC 3-57 
termination count . 
See SESSION COUNTS, termination count 
termination rule, bracket 


See bracket, bracket termination rule 
TEST_FOR_FREE_FSP_SESSION procedure 3-82 
referenced by 
ALLOCATE_RCB_PROC 3-26 
TEST_FOR_POST_SATISFIED procedure 5.1-60 
referenced by 
RECEIVE _AND_TEST_POSTING 5.1-50 
TEST_PROC 5.1-26 
TEST_FOR_RESOURCE_POSTED procedure 5.0-21 
referenced by 
WAIT_PROC 5.0-19 
TEST_PROC procedure 5.1-26 
referenced by 
MC_TEST_PROC 5.2-28 
PS_ CONV 5.1-10 
TEST_FOR_RESOURCE_POSTED 5.0-21 
TH 
See transmission header (TH) 
TH and RH parameters 4-14 
TP 
See transaction program instance (TP) 
TP-PS process 
See presentation services (PS), process 
See transaction program, process 
TPN 
See transaction program name (TPN) 
transaction control block (TCB) 3-4, 5.0-3, 
5.1-3, 5.2-4, 5.3-7, 5.3-8, 5.3-18, 5.3-20 
TRANSACTION_PGM_VERB structure 
processing by PS.COPR 5.4-25, 5.4-29 
transaction program 2-1; 2-4, 2-40 
See also transaction program code 
See also transaction program instance (TP} 
invoking initial (local) 2-2) 2-32, 2-44, 
3-5 
invoking remote 2-32, 3-5, 3-10 
process 2-40, 2-44 
protocol boundary 2-4, 2-27 
See also presentation services for con- 
versations (PS.CONV), protocol bounda- 
ries 
See also presentation services for 
mapped conversations (PS.MC), protocol 
boundaries 
See also presentation services for the 
control operator (PS.COPR), protocol 
boundaries 
terminating 2-32, 5.0-4, 5.0-5 
transaction program code 2-32 
See also transaction program 
transaction program instance (TP) 2-40, 3-10 
See also transaction program 
identifying 2-6 
limit 2-5, 3-2, 3-10, 5.0-6 
transaction program name (TPN) 2-5, 2-32, 
2-36, 2-40 
TRANSACTION_PROGRAM structure 2-40, 5.1-2; 
A-5 
referenced by 
ATTACH_PROC 3-30 
CREATE_TCB_AND_PS 3-45 
DEFINE_PROC 5.4-39 
DELETE _PROC 5.4-41 
DISPLAY_PROC 5.4-40 
PS ABEND PROC 3-54 
PS_CREATION_PROC 3-55 
PS_PIP_CHECKS 5.0-13 
PS TERMINATION PROC 3-57 
PURGE_QUEUED_REQUESTS 3-59 
START_TP_PROC 3-77 
transaction program verbs 2-3, 2-45 2-30; 
2-46, 5.1-4 | 
See also basic conversation 
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X-28 


See also presentation services for mapped 
conversations (PS.MC), protocol bounda- 
ries 

See also presentation services for the 
control operator (PS.COPR), protocol 
boundaries 

See also transaction program, protocol 
boundary : 

examples 2-18 

GET_TYPE verb 5.0-7 

issued by LU 2-30, 2-32) 2-36 

parameter checks 5.1-6 

POST_ON_RECEIPT 5.1-7 

REQUEST TO SEND 5.1-7 

SEND_ERROR 5.1-7 

state 5.1-6 

WAIT verb 5.0-7 

transaction services 2-36 
See also transaction program, protocol 
boundary 
transformation of uninterpreted name 4-18 
TRANSLATE procedure 6.1-49 
referenced by 
DFC_RCV 6.1-24% 
DFC_SEND_FSMS 6.1-27 
transmission control (TC) 
CRV 6.2-3 
initial chaining value 6.2-3, 6.2-4 
session cryptography Key 6.2-3 
session seed 6.2-3 
test value 6.2-3 
cryptography 6.2-1, 6.2-6 
block chaining 6.2-6 
Data Encryption Standard (DES) 6.2-7 
enciphering/deciphering 6.2-1, 6.2-6 
initial chaining value 6.2-3, 6.2-4¢ 
session cryptography Key 6.2-7 
session seed 6.2-3 

data traffic protocols 6.2-1 

deadlock 6.2-8 

deciphering 6.2-1, 6.2-6 

enciphering 6.2-1, 6.2-6 

expedited flow 6.2-1, 6.2-6 

HS-initiated procedure 6.2-6 

initial chaining value 6.2-3, 6.2-4 

ISOLATED PACING MESSAGE (IPM) 6.2-8 

ISOLATED PACING RESPONSE (IPR) 6.2-8 

normal flow 6.2-6 

pacing 

pacing queue 6.2-8 
Queued Response indicator (QRI) 6.2-8 
session-level 6.2-1 

QRI 6.2-8 

queued response indicator (QRI) 6.2-8 

receiving 6.2-1 

request control mode 6.2-7 

SEND_MU 6.2-6 

sending 6.2-1 

sequence numbers, TH 6.2-6 

assignment 6.2-6 
checking 6.2-1 
expedited flow 6.2-6 
identifiers 6.2-6 
initialization 6.2-6 
normal flow 6.2-6 
wrapping 6.2-6 
session cryptography Key 6.2-3 
session-level pacing 6.2-1, 6.2-6, 6.2-7 
IPM 6.2-8 
IPR 6.2-8 
pacing count 6.2-7 
PI 6.2-7,5 6.2-8 
stages 6.2-7 
window size 6.2-7 
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solicited pacing response 6.2-8 
structure | 
relation to the half-session 6.2-2 
SEND_MU and TC.RCV Request/Response 
Flow 6.2-5 
TC initialization 6.2-1 
TC normal operation 6.2-1 
TC.RCV 6.2-6 
transmission header (TH) 6.2-5 
transmission priority 6.2-8 
TS profile 7 6.2-6 
unsolicited pacing response 6.2-8 
transmission header (TH) 2-15, 2-17, 2-30 
session control 6.2-5 | 
transport characteristics 2-3 
See also mode, LU 
tree 
See logical unit of work (LUW), distrib- 
uted 
truncation of logical records 2-11, 2-14 
TRY_TO_RCV_SIGNAL procedure 6.1-23 os 
referenced by i | 
PROCESS_LU_LU SESSION 6.0-5 Sa 
TS (transmission services) profile 
in BIND 4-20 
TS profile 
See profiles 
TS profile 7 6.2-6 
TS Usage field 
in BIND 4-21 
two-way alternate send/receive protocol 
See half-duplex flip-flop send/receive 
mode 
type of session termination 4-28 2 


session seed 6.2-3, 6.2-6 (~ 
ne 


type, node 1-3 
See also node 
type, PU 1-5 
See also PU type 


is 


UNBIND 2-15, 2-34, 4-27 
session failure 2-31 


UNBIND_PROTOCOL_ERROR structure A-17 ame 
referenced by \ i 
PROCESS PS TO_RM RECORD 3-22 Suet 


PS _PROTOCOL_ERROR 5.0-20 
undefined protocol machine (UPM), definition 
of 1-5 
underscores, separating multiple terms of a 
name phrase 1-5 
uninterpreted LU name 4-18 
See also LU name 
interpretation of 4-18 
unit of work 
See sync point, logical unit of work 
UNRESERVE_BUFFERS procedure 4-85 
referenced by 
CLEANUP_LU_LU_SESSION 4-67 
UNSUCCESSFUL_SESSION_ACTIVATION proce- 
dure 3-83 
referenced by 
ACTIVATE_SESSION_RSP_PROC 3-25 
UPM (undefined protocol machine), definition 


of 1-5 ae 
UPM_ATTACH_LOG procedure 5.0-22 a 
referenced by ee 
ATTACH_ERROR_PROC 5.0-15 
UPM_EXECUTE procedure 5.0-22 
referenced by 


CO 


PROCESS_FMHS 5.0-10 
PROCESS_START_TP 5.0-11 
UPM_MAPPER procedure 5.2-46 
referenced by 
MC_CONFIRM PROC 5.2-21 
MC_DEALLOCATE_PROC 5.2-23 


MC_PREPARE_TO_RECEIVE PROC 5.2-26 


MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
PROCESS DATA_COMPLETE 5.2-33 


PROCESS _ERROR_OR_FAILURE_RC 5.2-31 


RCVD_SVC_ERROR_PURGING 5.2-42 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 


RECEIVE _INFO_PROC 5.2-30 
SEND_SVC_ERROR_PURGING 5.2-45 
UPM_RETURN_PROCESSING procedure 5.0-23 
referenced by 
DEALLOCATION_CLEANUP_PROC 5.0-18 
URC 
See user request correlation (URC) 
user-application node 1-3, 1-4 
See also node 
User Data field 
in BIND 4-22 
user ID, security 
See conversation-level security 
user of LU 2-1 
user request correlation (URC) 
in BIND 4-23 


varying dynamic buffer pool 
See buffer, pools 
varying dynamic buffers 
See buffer, types 
VERB_PARAMETER_CHECK procedure 5.4-48 
referenced by 3 
SOURCE_SESSION_LIMIT_PROC 5.4-%6 


i 


WAIT_FOR_CONFIRMED_PROC procedure 5.1-61 


referenced by 
COMPLETE_CONFIRM_PROC 5.1-28 
DEALLOCATE_CONFIRM_PROC 5.1-32 


PREPARE_TO_RECEIVE_CONFIRM PROC 5.1-41 


WAIT_FOR_RM_REPLY procedure 5.1-62 


referenced by 
ALLOCATE_PROC 5.1-11 
END_CONVERSATION_PROC 5.1-34 
OBTAIN_SESSION_PROC 5.1-37 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC proce- 
dure 5.1-63 
referenced by 
REQUEST_TO_SEND PROC 5.1-23 
WAIT_FOR_SEND_ERROR_DONE_PROC proce- 
dure 5.1-64 
referenced by 
DEALLOCATE_ABEND_PROC 5.1-31 


SEND_ERROR_IN_RECEIVE_STATE 5.1-56 


WAIT_PROC procedure 5.0-19 
referenced by 
PS_VERB_ROUTER 5.0-16. 
Window size 
session-level pacing 6.2-7 
adaptive pacing 6.2-7 
fixed pacing 6.2-7 
winner, contention 
See bracket, first speaker 
workstation 
See resource, local 


XO6F1l procedure 5.4-57 


YIELD_SESSION structure A-19 
referenced by 
DFC_SEND_FROM_RM 6.1-21 


SUCCESSFUL_SESSION_ACTIVATION 3-81 
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